Subject: [dane] DANE and STARTTLS - indication of availability of encryption

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 3 Sep 2013 18:31:33 -0700

RFC6698 contemplates the use of DANE records with SMTP. (_25._
tcp.mail.example.com is given as an example in the document). However, one
of the problems with SMTP is that it's not known to the sending server
whether the receiving server supports STARTTLS a-priori. (One connects to
the SMTP server, issues an EHLO command and is informed whether the server
supports STARTTLS or not. This can be trivially removed by a malicious
MITM). Similar downgrade vulnerabilities exist for other protocols that
rely on STARTTLS-type commands.

DANE lets one specify what certificate is acceptable if a certificate is
required, but not whether a certificate should be expected. I'm curious to
know if there's any appetite to allow this information to be conveyed via a
DANE record. For instance, again with SMTP as an example, one can remember
whether STARTTLS was offered on a previous connection to try to protect
against downgrade attacks, but this is rather brittle, doesn't work well
for new / long-tail hosts, and it's not clear in such a scenario if someone
simply disabled STARTTLS intentionally or if it's actually representative
of an attack.

One could use DANE to convey, for STARTTLS-type services, whether a client
should treat the lack of encryption support as a fatal error or not. One
possible way to achieve this would be using the high bit of the certificate
usage octet to specify whether the TLSA is advisory ("if you get a
certificate from me, it must match in the following manner") or mandatory
("I offer certificates that match in the following form, if you are unable
to obtain a certificate from me treat it as a hard failure"). I'm not stuck
on the particulars of which bit gets used or where it gets implemented,
other than it would be nice (from my perspective) if it could be combined
in an existing record rather than having to fetch yet another RR for just
one bit of information.

Fundamentally, the problem I'm trying to solve is the problem of downgrade
attacks against protocols like SMTP that advertise their STARTTLS
capability in the clear. It seems like DANE, where one is specifying a
policy about how to validate a TLS connection, might be a reasonable fit
for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP or
any other protocol) should be expected or not. I'm not sure if this has
been considered or not.

Thoughts welcome.
-Ian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Sep 2013 12:25:33 +1000

In message <CAF4kx8fSVL5UouVgJubkrNj=BJAyV=[email-masked]>, =?UTF-8?B?SWFuIEZldHRlI
CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes:
> --===============5680513047430573670==
> Content-Type: multipart/alternative; boundary=047d7bd7689804b84f04e584c415
> 
> --047d7bd7689804b84f04e584c415
> Content-Type: text/plain; charset=UTF-8
> 

The presence of the rrset prevents the downgrade attack.  A validating
resolver can detect when there should be a RRset but it is not being
returned.  The STARTTLS client then expects to see STARTTLS in the
EHLO response if it has a TLSA RRset.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andy Wilson <[email-masked]>
Date: Wed, 4 Sep 2013 14:33:18 +1200

I would agree with Mark.
It's based on local policy ultimately. One would assume if a TLSA RR exists
for a host on port 25, a certificate will be presented.
STARTTLS would be handled a little differently of course (send a EHLO first
etc. instead of ClientHello for TLS) but this is down to implementation.

On 4 September 2013 14:25, Mark Andrews <[email-masked]> wrote:

>
> In message <CAF4kx8fSVL5UouVgJubkrNj=BJAyV=
> [email-masked]>, =?UTF-8?B?SWFuIEZldHRlI
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
Regards

Andy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Sep 2013 03:21:46 +0000

On Tue, Sep 03, 2013 at 06:31:33PM -0700, Ian Fette (????????) wrote:

> However, one of the problems with SMTP is that it's not known to
> the sending server whether the receiving server supports STARTTLS
> a-priori.  Similar downgrade vulnerabilities exist for other
> protocols that rely on STARTTLS-type commands.

This is well understood, and downgrade resistance is built into:

    https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01

as well as the earlier:

    https://tools.ietf.org/html/draft-ietf-dane-srv-02

and not surprisingly into the Postfix DANE implementation, currently
available in the 2.11-20130825 snapshot from www.postfix.org or
from the Debian experimental package repository.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 3 Sep 2013 20:59:24 -0700

" The STARTTLS client then expects to see STARTTLS in the
EHLO response if it has a TLSA RRset." - this wasn't clear from my reading
of the RFC. Where is that specified, or well understood? If that's a safe
assumption, that certainly simplifies things, but this was not clear from
my (admittedly hurried) reading of the RFC.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Sep 2013 04:02:22 +0000

> my (admittedly hurried) reading of the RFC.

See my earlier reply.

Downgrade-resistant opportunistic TLS is out of scope for RFC 6698,
this subject will be covered in various application-specific documents
that specify how DANE is to be used for the protocol in question.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 3 Sep 2013 21:13:32 -0700

Viktor,

I was just getting to your email :) Thanks for pointing out
https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 -
something like this seems quite useful in codifying the expectation of
STARTTLS support for SMTP (or other protocols) given that a TLSA record
exists.

I'm not sure that I agree with everything in that draft, particularly the
bit about not using certificate usage 0/1, as this is precisely what we
would do for Gmail most likely (we operate our own CA, and for instance in
Chrome and via http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we
typically pin google.com to a set of CA certificates, not leaf
certificates, as the leaf certificates can rotate more frequently based on
operational needs but our CA cert changes much more rarely.) It's not clear
to me why requiring PKIX validation in that case would be an unreasonable
expectation. Indeed, most of the certs I see from a random inspection of
servers offering STARTTLS (google, t-online, web.de etc) include a full
certificate chain to a public CA. Other than that nit though, I would love
to see that draft advance.

-Ian

---

From: Andreas Schulze <[email-masked]>
Date: Wed, 04 Sep 2013 08:32:52 +0200

Zitat von Viktor Dukhovni <[email-masked]>:

> available in the 2.11-20130825 snapshot from www.postfix.org

reading this I tried to verify it.
and: it works!

I have an smtp server with an associated dane record.
A client could establish a trusted tls session without knowing any  
root certificates
( empty smtp_tls_CAfile and smtp_tls_CApath )
The trust based only on dnssec and dane.

If I now disable STARTTLS at the server, the client do not send the  
message without TLS:
"TLS is required, but was not offered by host ..."

That's a usable downgrade prevention.
Thanks!

Andreas

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 4 Sep 2013 14:38:01 +0200

Ian,

On 4. 9. 2013, at 6:13, Ian Fette (イアンフェッティ) <[email-masked]> wrote:
> I'm not sure that I agree with everything in that draft, particularly the bit about not using certificate usage 0/1, as this is precisely what we would do for Gmail most likely (we operate our own CA, and for instance in Chrome and via 

You need certificate usage 2 for your own CA and the mapping 0->2, 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE record with certificate usage 0 SHOULD be used even in case that you use a well established CA.

> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we typically pin google.com to a set of CA certificates, not leaf certificates, as the leaf certificates can rotate more frequently based on operational needs but our CA cert changes much more rarely.) It's not clear to me why requiring PKIX validation in that case would be an unreasonable expectation.

I guess this comes from operational experiences, currently the SMTP servers don't do any validation on the certificates and it would be a great leap to take, so it's better to start with opportunistic TLS than enforcing the users to do full PKIX.

This might change in the future in some future draft, but Viktor's draft would be a huge leap for SMTP encryption.

> Indeed, most of the certs I see from a random inspection of servers offering STARTTLS (google, t-online, web.de etc) include a full certificate chain to a public CA. Other than that nit though, I would love to see that draft advance.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Sep 2013 14:45:49 +0000

On Tue, Sep 03, 2013 at 09:13:32PM -0700, Ian Fette (????????) wrote:

> operational needs but our CA cert changes much more rarely.)

Do not confuse non-support of 0/1 with not supporting CA-anchored
certificate chains.  In my SMTP draft the latter are fully supported
via usage 2.

The difference is that the SMTP client is *not expected* to have
any prior knowledge of a set of CAs trusted collectively to
authenticate the entire Internet.  Any such set of CAs is either
incomplete (mail delivery to some sites fails) or contains CAs one
should generally trust (one can't be sure exactly which ones those
are).   Think of this as a variant of Goedel's incompleteness
theorem to trusted CAs as a set of axioms for Internet security. :-)

Furthermore, since sites are allowed to publish self-issued
certificate associations (e.g. to a 3 1 1 leaf public key,
or to a 2 1 1 domain issued CA), any attacker who compromises
a domain's DNS can substitute any TLSA records that require
PKIX (usage 0 or 1) with records that don't (2 or 3).

In fact since you observed the trivial downgrade attacks on SMTP
without DANE, if such an attacker can also MITM the client, he
can simply suppress the TLSA records, an not send STARTTLS.  The
client then sends mail in the clear.

Most MTAs do not ship with a complete (inconsistent) set of CAs.
Since unlike a browser there is no interactive user to click "OK"
when PKIX verification fails, requiring PKIX would lead to degradation
in reliability of service.  Some MTAs are configured with a short
of lists CAs the administrator actually trusts (incomplete), they
use this for manually configured PKIX validated delivery to selected
partner sites, but this does not scale to the Internet, and is not
dependent on DANE.

Non-support of certificate usages 0/1 in the SMTP incarnation of
DANE is key to the interoperability of the protocol with existing
systems and flows naturally out of a thoughtful security analysis
of the protocol.

If you publish usage 0, you will not interoperate with Postfix,
which accounts for a large fraction of the MTAs on the Internet.

Google is of course free to configure its own SMTP clients with
prior knowledge of Google's CA, so that mail delivery internal to
Google is protected by additional client-side security policy.
Nothing in my draft precludes this, but no such prior configuration
scales to the Internet at large.

You should perhaps have a chat with Warren Kumari (one of the chairs
of the DANE working group, and a Google employee I believe).  If
you want to include me in the conversation, let me know and I may
be able to join you in a conference call.

> It's not clear

You've only looked at the major providers.  The majority of domains
that offer SMTP STARTTLS have self-signed certificates.  In any
case SMTP clients (even at large Fortune 500 companies that pay
for certs issued by public CAs) almost never check the CAs of other
SMTP servers except by bilateral prior arrangement.

When I worked for Morgan Stanley, we were pretty much the only
company that actually went beyond enforcing mandatory use of TLS
and configured verification of the peer certificate.  Most of our
business partners were content to require "encryption" without any
authentication.

Doing PKIX with SMTP is hard in any case because MX indirection
(sans DNSSEC) makes it impossible to robustly determine what names
are acceptable in the peer's certificate.

So bottom line, my draft is carefully thought out, and the requirement
to NOT publish usage 0/1 is very unlikely to change.  This is not
a draft built in a vacuum, hoping for eventual adoption by some
implementor.  Rather this is a draft that adheres to an actual
implementation in Postfix, and soon (when the relevant Exim developer
is able to take time to make it happen) also in Exim.

The draft documents a basis for interoperability with *existing*
implementations, and the core features should not be changed without
compelling reasons to do so.

On Wed, Sep 04, 2013 at 02:38:01PM +0200, Ond?ej Sur? wrote:
> 
> > I'm not sure that I agree with everything in that draft,
> > particularly the bit about not using certificate usage 0/1, as this
> > is precisely what we would do for Gmail most likely (we operate
> > our own CA, and for instance in Chrome and via
> 
> You need certificate usage 2 for your own CA and the mapping
> 0->2, 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your
> DANE record with certificate usage 0 SHOULD be used even in case
> that you use a well established CA.

The Postfix mapping of usage 0 to 2 is necessarily incomplete!  In
particular "0 x [12]" are unsupported, and "0 0 0" is too large to
fit into DNS without fragmentation.  Even "0 1 0" is too large with
2048-bit RSA keys.  Only ECDSA keys make "0 1 0" usable, but most
clients don't support EC.

So in effect only the downgrade of 1->3 works.  Usage "0" is
essentially not supported at all (best effort support leaves most
of it unusable).

> > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we
> > certificates, as the leaf certificates can rotate more frequently
> > based on operational needs but our CA cert changes much more rarely.)
> > It's not clear to me why requiring PKIX validation in that case
> > would be an unreasonable expectation.
> 
> I guess this comes from operational experiences, currently the
> SMTP servers don't do any validation on the certificates and it
> would be a great leap to take, so it's better to start with
> opportunistic TLS than enforcing the users to do full PKIX.
> 
> This might change in the future in some future draft, but Viktor's
> draft would be a huge leap for SMTP encryption.

This is very unlikely to change.  I can't subject Postfix users to
the consequences of requiring PKIX (reduced service availability
when CA lists are incomplete, or mandating trust in CAs they've
never heard of).  Adding CA trust in SMTP with DANE adds no security,
the protocol is critically dependent on DNSSEC.  So PKIX for SMTP
(internet scale with no prior bilateral agreement, ... see the
draft) only gives us additional failure modes with no security
benefit.  There will be no PKIX support in the Postfix DANE
implementation.

Servers publishing usage 0 will find that clients simply enforce
mandatory TLS and skip authentication.  The right thing to do is
to choose between publishing "2 1 1" or "3 1 1".  The remaining
22 combinations of DANE parameters can be ignored for SMTP.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 4 Sep 2013 08:13:30 -0700

Ondřej, I might be getting it wrong, but since our CA is cross-signed by
another CA, the chain that most clients will build will be rooted in
something else. You can see this if you go to https://mail.google.com -
GeoTrust shows as the root, which signs Google Internet Authority G2, which
signs a cert for mail.google.com. If someone is using openssl and it
follows AIA chaining or otherwise constructs a trust chain up to GlobalSign
and we had specified "2" with the intermediate, would that break or still
work? (Sorry, this is probably the most confusing part of the spec)

On Wed, Sep 4, 2013 at 5:38 AM, Ondřej Surý <[email-masked]> wrote:

> > I'm not sure that I agree with everything in that draft, particularly
> the bit about not using certificate usage 0/1, as this is precisely what we
> Chrome and via
> You need certificate usage 2 for your own CA and the mapping 0->2, 1->3
> (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE record with
> certificate usage 0 SHOULD be used even in case that you use a well
> established CA.
>
> expectation.
> I guess this comes from operational experiences, currently the SMTP
> servers don't do any validation on the certificates and it would be a great
> leap to take, so it's better to start with opportunistic TLS than enforcing
> the users to do full PKIX.
>
> This might change in the future in some future draft, but Viktor's draft
> would be a huge leap for SMTP encryption.
>
> > Indeed, most of the certs I see from a random inspection of servers
> offering STARTTLS (google, t-online, web.de etc) include a full

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Sep 2013 15:20:20 +0000

On Wed, Sep 04, 2013 at 08:13:30AM -0700, Ian Fette (????????) wrote:

> Ond?ej, I might be getting it wrong, but since our CA is cross-signed by

Usage 2 chains work just like PKIX chains with the additional
freedom that the trust-anchor need not be a root CA previously
known to the client.

If you also read

    https://tools.ietf.org/html/draft-dukhovni-dane-ops-01

you'll see that since the client will typically not have the associated
CA certificate on hand, the server's certificate chain (sent in the
TLS handshake) must include the trust anchor certificate.

If the trust-anchor in a TLSA "2 1 1" record is an intermediate
CA, the above will typically already be the case.  When the "2 1
1" trust-anchor is actually a root CA (I encourage you to use a CA
as close as possible to the leaf server that is stable enough to
publish in your TLSA RRs) you now need to make sure that it is
sent in the TLS handshake since unlike the PKIX case, the client
won't have it on hand.

-- 
	Viktor.

---

From: [email-masked]
Date: Wed, 04 Sep 2013 17:23:25 +0200

On 2013-09-04 17:13, Ian Fette wrote:
> Ondřej, I might be getting it wrong, but since our CA is cross-signed
> by another CA, the chain that most clients will build will be rooted
> in something else.

The usual problem is that the CA store in SMTP servers is empty by 
default
and people usually (somebody should probably do some survey) use 
self-signed
certs/CAs for their SMTP service.

> You can see this if you go to
> https://mail.google.com [7] - GeoTrust shows as the root, which signs
> Google Internet Authority G2, which signs a cert for mail.google.com
> [8]. If someone is using openssl and it follows AIA chaining or
> otherwise constructs a trust chain up to GlobalSign and we had
> specified "2" with the intermediate, would that break or still work?

It would still work if you send whole chain in the TLS up to the 
certificate specified in TLSA record.

O.

> (Sorry, this is probably the most confusing part of the spec)
> 
>> is precisely what we would do for Gmail most likely (we operate our
>> own CA, and for instance in Chrome and via
>> 
>> You need certificate usage 2 for your own CA and the mapping 0->2,
>> 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE
>> record with certificate usage 0 SHOULD be used even in case that you
>> use a well established CA.
>> 
>>> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [1]
>> we typically pin google.com [2] to a set of CA certificates, not
>> leaf certificates, as the leaf certificates can rotate more
>> frequently based on operational needs but our CA cert changes much
>> more rarely.) It's not clear to me why requiring PKIX validation in
>> that case would be an unreasonable expectation.
>> 
>> servers don't do any validation on the certificates and it would be
>> a great leap to take, so it's better to start with opportunistic TLS
>> than enforcing the users to do full PKIX.
>> 
>>> Indeed, most of the certs I see from a random inspection of
>> servers offering STARTTLS (google, t-online, web.de [3] etc) include
>> a full certificate chain to a public CA. Other than that nit though,
>> I would love to see that draft advance.
>> 
>> O.
>> --
>>  mailto:[email-masked]    http://nic.cz/ [4]
>>  tel:+420.222745110 [5]       fax:+420.222745112 [6]
> Links:
> ------
> [1] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08
> [2] http://google.com
> [3] http://web.de
> [4] http://nic.cz/
> [5] tel:%2B420.222745110
> [6] tel:%2B420.222745112
> [7] https://mail.google.com
> [8] http://mail.google.com

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 4 Sep 2013 08:25:56 -0700

Viktor,

Thanks for the continued considered replies. I don't mean to ignore you,
it's just that I typically reply in chronological order and hadn't yet
finished writing a response to your email :)

Much of this probably stems from my confusion around 0/2 in the DANE spec.
0 says the cert MUST be found in the path - it doesn't say the cert has to
be the root. 2 implies that the cert has to be the root. For us, the thing
we want to pin to (our intermediate CA) would be in the middle of the
chain, so I had read that to imply that only 0 would be available. What I
hear you saying is that it would still work with pinning to that
intermediate using 2, and presumably the client should use the cert in 2 as
the root of the trust chain and ignore any signatures on that root from
other CAs it knows about. This wasn't entirely clear to me in the spec, but
if that's how it is supposed to work, then yes, I believe that would work
for our use case.

-Ian

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Sep 2013 15:56:21 +0000

> Much of this probably stems from my confusion around 0/2 in the DANE spec.

Perhaps 6698 could be more clear, but this is a general issue with
standards documents, they are always too concise unless one is
steeped in the art.

> be the root.  2 implies that the cert has to be the root.

You're misreading the specification.  In both cases the certificate can
be anywhere in the path.  With 0, the client is required to have prior
trust in an additional root CA to anchor the path.  With 2 the requirement
is dropped.

The trust-anchor in usage 2 can be an intermediate certificate or
a root certificate.  As far as the DANE client is concerned of course
path construction can terminate at the usage 2 TA, and need not go any
higher.  However, the actual usage 2 TA may be an intermediate from
a PKIX perspective and may be issued by some "authority", ...

> For us, the thing
> chain, so I had read that to imply that only 0 would be available.

You're misreading the specification.  Go ahead and pin the intermediate
with usage 2, this just works.  Best practice for your case is to
publish a "2 1 1" association that is a SHA256 digest of the
intermediate CA's public key.

> What I hear you saying is that it would still work with pinning to that

Yes, that's how it is meant to work.  A thorough and careful reading
of 6698 should make this clear, even if it is not obvious at first
glance.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Wed, 04 Sep 2013 17:33:16 -0400

>>>>> "IF(" == Ian Fette (イアンフェッティ) <[email-masked]> writes:

IF(> Ondřej, I might be getting it wrong, but since our CA is cross-signed by
IF(> another CA, the chain that most clients will build will be rooted in
IF(> something else.

2 can point at any cert in the full chain other than the ee cert.  The
client is expected to verify from the ee to the cert specified in the 2,
and then verify that /that/ cert matches the tlsa.

You can also do that with a 0.  If you use 0, then clients are typically
expected to do the above, but *also* verify the full chain just as they
would w/o DANE.

Pointing at the google ca with type 0s would be fine for everything you
serve at a fixed port over tls or dtls, given that you have a corp CA
which has been signed by a well-known root CA.  But only if clients
which do not know the typical ca-certificates.crt choose to pretend that
the type 0 were a type 2, as Victor’s draft recommends.  And as his
postfix code does.

Some suggest using a CNAME to point at a single TLSA RR to improve
caching (the CNAME RRs require fewer bits than the TLSA, so a lot of
CNAME RRs pointing at one TLSA probably is better than a lot of TLSA RRs
with identical content.  (Hint to self.)

Most smtp client admins do not bother to configure the list of CAs, so
most could not do full type 0 or type 1 verification.  Some of us do,
however, configure it, do check the offerred certs when sending mail,
but cannot, yet, require that they pass.  There are too many MXs which
can only to untrusted tls.

Since I point my outgoing postfix at:

      smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

I get logs like:

	Trusted TLS connection established to
	    gmail-smtp-in.l.google.com[2607:f8b0:4002:c04::1b]:25: 
	    TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

(Interesting that the MXs still prefer rc4; the other goog TLS services
recently switched to negotiating TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256.)

But cannot demand Trusted, due to sites like:

	Untrusted TLS connection established to
	    mail.ZZZZZZ.org[NNN.NNN.NNN.NNN]:25:
	    TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
or:
	Untrusted TLS connection established to
	    mx.ZZZ.org[NNN.NN.NN.NN]:25:
	    TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

(names elided to protect the untrusted :).

The inability to demand Trusted is likely why most do not bother to
configure the CAfile.  In fact it is only in that last year or so that
most of my outgoing mail has been to MXs which even offer starttls.

DANE should help that.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: James Cloos <[email-masked]>
Date: Wed, 04 Sep 2013 19:43:20 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> If you publish usage 0, you will not interoperate with Postfix,
VD> which accounts for a large fraction of the MTAs on the Internet.

I thought that you previously wrote that, in the absense of of CAfile
setting, postfix would treat 0/1 like 2/3?  Or did I miss a change?

Ian:  Given the above, my earlier post suggesting type 0 would do
      should be amended to suggest a type 2 for _25._tcp.

      I still would choose 2 rather than 3 in your case, since you can
      issue new ee certs signed by that CA at will.  Saving the hassle
      of updating the DNS every time that occurs is a good plan.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Sep 2013 01:09:24 +0000

> setting, postfix would treat 0/1 like 2/3?  Or did I miss a change?

The mapping from 0/1 to 2/3 is best effort.  With 1 it just works,
with 0 it fails with matching type != 0.

Also Wes convinced me that we should not promise this behaviour in
the draft.  Therefore, while Postfix may map 0/1 to 2/3 as best it
can the draft behaviour for these is undefined and SMTP servers
SHOULD NOT publish these usages.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 5 Sep 2013 14:17:39 -0700

One other question about this proposal.

My reading of DANE says that if a TLSA record is not verified by DNSSEC,
you should basically ignore it. Precious few people have yet deployed
DNSSEC (Paypal is the only company that comes to mind). If a zone hasn't
deployed DNSSEC, I certainly understand not treating a TLSA record on _443._
tcp.bank.com as a valid SSL certificate for https://www.bank.com. But what
about the case of SMTP? On SMTP, today you're going to connect on port 25,
and you're going to either not see STARTTLS in which case you presumably
will send mail unencrypted, or you will see STARTTLS and as we discussed
earlier in this thread, probably just take whatever certificate you get and
hope for the best.

Now, let's assume you have a TLSA record for _
25.tcp.gmail-smtp-in.l.google.com, which specifies 2 1 1 and our
certificate. Let's assume also for the moment that it's not secured via
DNSSEC, and that DNSSEC deployment for google.com isn't going to happen
overnight. Now, you've got an option. You can use that (admittedly
insecure) information and do one of three things:

1. Ignore it and do what you would have done had you not seen the TLSA
record (per the DANE spec)
2. Ignore the fact that it's lacking DNSSEC and treat it as "I should only
send mail over TLS and expect the following cert"

I'm curious what Postfix will do in that case, and what guidance we might
be able to put into the draft in that case. For better or worse, there's
probably others who are capable of publishing a TLSA record before they are
capable of fully deploying DNSSEC.

In the case of someone being able to spoof your DNS, they could just direct
the MX records elsewhere, and not bother with spoofing TLSA (maybe they
offer STARTTLS, maybe they don't). It doesn't seem like trusting the TLSA
record opens you up to any new vulnerabilities here. In the case of HTTP,
it does open you up to vulnerabilities as you presumably send secure
cookies to a certificate you otherwise wouldn't have trusted. In the case
of SMTP, you basically either bounce the mail or you deliver it; someone
who can publish a fake TLSA record to mess with you could just as easily
publish fake MX records to accomplish the same result, so it's not clear to
me that a TLSA record for MX need to depend strongly on DNSSEC.

Thoughts?

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Sep 2013 17:29:33 -0400

> send mail over TLS and expect the following cert"

Why do you think (2) provides any advantage over (1)?  If someone is
actually in a position to MITM your SMTP connections, surely spoofing
the odd TLSA record is going to be pretty easy, no?  The only
protection you have in that case is DNSSEC, I think?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Sep 2013 21:56:48 +0000

On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (????????) wrote:

> you should basically ignore it.

Correct.  RFC 6698 specifies that TLSA RRs are only valid in "secure" zones.

> On SMTP, today you're going to connect on port 25, and you're going
> to either not see STARTTLS in which case you presumably will send
> mail unencrypted, or you will see STARTTLS and as we discussed
> earlier in this thread, probably just take whatever certificate
> you get and hope for the best.

If all you want is protection against passive eavesdropping,
opportunistic TLS (without DANE) is sufficient.  The attacker cannot
suppress STARTTLS (after all the attacker is *passive* by hypothesis).

If you have an active attack (man in the middle), where STARTTLS
can be supress, it is trivial to also supress insecure DNS responses.
In fact, for many adversaries, it is likely easier to forge DNS
replies than to interpose themselves into the middle of a network
connection.

So I don't think there's much point in processing insecure TLSA
responses.  Postfix typically does not even bother with the query.
TLSA RRs are queried for each MX host only when the MX RRset was
secure.  When the MX host names can't be trusted, no TLSA query is
issued.  So bottom-line, no support for insecure TLSA RRs in Postfix
at this time.

Postfix also has a "dane-only" security mode which can be enabled
for selected destinations.  This requires successful DANE authentication
of the destination's SMTP servers, the code for that use-case
definitely must not honour insecure TLSA RRs, and it would complicate
the implementation to handle DNS lookups for "opportunistic" and
"mandatory" DANE differently.

In terms of DNSSEC adoption, aside from paypal.com, which is in a
very different market segment, comcast.net and comcast.com have
been secured with DNSSEC for quite some time now.  They have not
yet published TLSA RRs for their MX hosts, if anyone knows the
email administrators at comcast well enough to nudge them in
the right direction, please do so...

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 5 Sep 2013 14:57:24 -0700

Let's say that you want to know a-priori if an email will be sent over TLS.
Three german companies are doing this already ("Email made in germany"
campaign between web.de, gmx, and t-online) where they show their users
distinguishing UI if the mail is being sent "securely". It's an interesting
to see how that would work out, and personally I find it a very difficult
UI challenge to communicate something meaningful that won't be
misinterpreted, but anyhow... (2) gives you a signal that you could
potentially pass on to a user, and then the user can potentially make a
decision about whether or not they want to send the email. I think it needs
a bit more thinking and UX studies as to whether or not this is a good
idea, but having a signal like that does enable such use cases.

It also provides a signal that services can potentially cache as to whether
the recipient believes their STARTTLS support is reliable or not. E.g. if
we see such a record and don't see STARTTLS, we may decide to bounce (or
hold) the message until we see STARTTLS again. If we've seen that record
and it disappears as well as STARTTLS support disappearing, that might be a
stronger signal that there's a potential MITM attack or strangeness than
simply seeing STARTTLS disappear alone.

Basically, it's extra information, which opens up a few possibilities, and
although it doesn't itself prevent an active MITM who is capable of DNS
cache poisoning, it does provide extra information for use in heuristics
and doesn't "hurt".

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 5 Sep 2013 15:12:05 -0700

You mention that you only bother if the MX RRset was secure.

In the Gmail case, we've got a lot of customers using "google apps for your
domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM

Let's say hypothetically ianfette.com has an MX record for
ASPMX.L.GOOGLE.COM but the administrator of ianfette.com can't be bothered
to set up DNSSEC. That implies that even if google.com had deployed DNSSEC
and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Sep 2013 22:24:10 +0000

> You mention that you only bother if the MX RRset was secure.

Correct.

> domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM

Yes, I've seen such domains.

> and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored?

Correct.  A chain is only as strong as its weakest link.  When the
original MX RRset is insecure, the base domain for the TLSA RR is
subject to compromise.  There is then no point in making TLSA
lookups even if the MX host domain is DNSSEC validated.

A domain only benefits from DANE, when *it* adopts DNSSEC.  If it
out-source MX service, the hosting domain also needs adopt DNSSEC.

	; client record in signed zone
	;
	example.com.	IN MX 0 mx.example.net.

	; provider record in signed zone.
	;
	mx.example.net. IN A 192.0.2.1
	_25._tcp.mx.example.net. IN TLSA 3 1 1 ...

If either zone is insecure, TLSA records are ignored.

I think this should not dissuade you from implementing DANE, there
are plenty of users to protect in gmail.com itself.  If client
domains have more reason to implement DNSSEC, that's for the better.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 5 Sep 2013 15:34:30 -0700

It seems like we're letting the perfect be the enemy of the good. At the
end of the day, what I would like to signal is that servers should expect
to talk to Google's mail servers using TLS. I would also like to know what
servers expect Google to talk to them using TLS. There are a few ways I can
think of accomplishing this, one being DANE, another being something
similar to HSTS (RFC6797), and I'm sure we can come up with a fair number
of other mechanisms as well. Each of them has their drawbacks. I would love
it if I could deploy DNSSEC on google.com tomorrow, but much as I may want
that it's not going to happen overnight. HSTS-style approaches don't let me
know a-priori what to expect from a new domain, but given our scale that's
not actually such a huge problem. As such, I'm trying to understand what
incremental steps I actually _can_ take. And so here we are choosing
between options that offer some additional benefit but don't solve all
problems, as is often the case in the messiness of the real world, and I'm
hoping that perfect need not be the enemy of the good.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Sep 2013 00:23:44 +0000

On Thu, Sep 05, 2013 at 03:34:30PM -0700, Ian Fette (????????) wrote:

> It seems like we're letting the perfect be the enemy of the good.

Not really.  Rather, one should resist the urge to draw overly
close analogies between the security models of SMTP and HTTP.

1.  With HTTP the security properties of the channel are encoded in
the destination address (URL) and connections are *direct* to the
selected destination.  With SMTP there is no security indication
in the email address, and deliveries are indirect via MX records.

2.  With HTTP there is typically an interactive user to click OK, with
MTA to MTA SMTP there is not.

3.  With HTTP the user is often found at WiFi hotspots and other
high risk for MITM environments.  With MTA to MTA SMTP, the networks
are generally over fixed wiring in more physically secure locations.

4.  With HTTPS the application protocol inside SSL/TLS, the client
needs prior knowledge of whether to connect over SSL.  With MTA to
MTA SMTP TLS is negotiated over SMTP, there is no need for prior
configuration.

> At the
> to talk to Google's mail servers using TLS.  

STARTTLS already does this, with each and every SMTP connection.
An MITM attacker can simply redirect the SMTP client to a different
set of MX hosts.

> I would also like to know what servers expect Google to talk to
> them using TLS.

Those would be the ones that respond with STARTTLS.  With DANE,
this response becomes downgrade resistant, and provides certificate
associations that make it possible to authenticate the peer MTA
even when it is (as most are) self-issued.  I strongly encourage
you to consider implementing DANE in the Google SMTP client.  This
does not require Google to sign their own domains, just query a
DNSSEC-aware resolver (akin to the ones offering the public DNS
service on 8.8.8.8).

> There are a few ways I can
> similar to HSTS (RFC6797).

HSTS is not terribly useful for SMTP.  Given MX indirection, and
relatively short MX TTLs, the attacker need only wait for the
next MX query, and HSTS is defeated.  Caching MX RRs beyond the
advertised TTL is not a viable option.

> I would love it if I could deploy DNSSEC on google.com tomorrow, but
> much as I may want that it's not going to happen overnight.

Yes, but perhaps between you, Warren, perhaps Ben and others, the
immovable object might budge after all.

> HSTS-style approaches don't let me
> incremental steps I actually _can_ take.

As an initial step it is enough to support STARTTLS in both the
SMTP client and server roles.

To harden this against active MITM attacks, sadly you need to harden
DNS, as the SMTP destination is determined indirectly via DNS MX
lookups.  SMTP security is not possible without DNS security.

> And so here we are choosing

DANE is definitely not perfect, but it fits the requirements of
downgrade resistant opportunistic TLS for SMTP.

It is tempting to apply lessons learned in browser security to
SMTP, but many don't carry over.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 5 Sep 2013 18:17:55 -0700

reply inline

> MTA to MTA SMTP there is not.

Presumably T-Online, web.de and GMX believe that by indicating to a user
a-priori whether their email will be sent over an encrypted channel, that
the user will make some decision. (See
http://www.e-mail-made-in-germany.de/Kennzeichnung.html) - so there is
potentially an opportunity for a user decision.

> are generally over fixed wiring in more physically secure locations.

Wouldn't this argument make DNSSEC less important, if you believe that the
MTA-MTA connection is less susceptible to MITM?

> MTA SMTP TLS is negotiated over SMTP, there is no need for prior

I don't know if I would say "no need". We would like to send email only
over TLS if we know the other end is TLS aware. Unfortunately, it's
difficult to determine if someone is experimenting with TLS on some of
their hosts (some servers seem to sporadically advertise STARTTLS and it's
not clear if they expect it to be 100% or if they're experimenting), or
whether they would expect us to hard fail. I'd love to be able to say to a
host "If you do X, we will consider the absence of STARTTLS in your EHLO
response to be a critical error and bounce the message".

> An MITM attacker can simply redirect the SMTP client to a different

Yes, which is why I would like a way to signal something more permanent and
noticeable than the context of a single SMTP connection. I'd be fine
putting a 1 week TTL on a TLSA record; yes it's possible that someone
attempts DNS cache poisoning though this is perhaps a bit more difficult
with a larger TTL.

> DNSSEC-aware resolver (akin to the ones offering the public DNS

It's something we're considering among other options, though it's difficult
for us to expect others to deploy this if we ourselves can't deploy it.

> advertised TTL is not a viable option.

Depends on what you tie HSTS to. In the HTTP case, the HSTS indication is
"Thou shalt connect to xyz.com over HTTPS". The TTL of that indication is
divorced from the TTL of the A record for xyz.com.

> immovable object might budge after all.

I would love that, but I would also love something I could deploy sooner
than Warren, Ben and others are likely to be able to deploy dnssec for
google.com :)

> SMTP client and server roles.

We already do (and even offer a valid certificate, no less). We'd like to
do more. Hence this massive email thread :)

> lookups.  SMTP security is not possible without DNS security.

You say SMTP security is not possible without DNS security. One could say
the same thing about HTTP security and yet that has not stopped us from
making improvements in that area (be they HSTS, certificate pinning,
certificate transparency, or any number of other attempts at making
incremental improvements without relying on DNSSEC deployment.)

> downgrade resistant opportunistic TLS for SMTP.

Agreed, unfortunately I can't satisfy all of its prerequisites at the
present point in time.

> SMTP, but many don't carry over.
I agree. And FWIW, I also agree with most of your points here about
deploying without DNSSEC leaving vulnerabilities open, some of which you
have enumerated. However, I've yet to hear a good argument for why one
would ignore information not protected by DNSSEC. In the case of a TLSA
record for HTTPS/443 I understand, I don't understand why one would ignore
that information for SMTP/25.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Sep 2013 01:35:32 +0000

On Thu, Sep 05, 2013 at 06:17:55PM -0700, Ian Fette (????????) wrote:

> However, I've yet to hear a good argument for why one

As an MTA developer, I can't think of anything useful I can do with
an unauthenticated TLSA record, that I don't already get with
STARTTLS.

Recall that TLSA records for SMTP are published for the MX hosts
only, not the domain.  Some of the MX hosts for a domain may support
DANE TLSA, others might not.  SMTP is very different from HTTP.

So even if see long TTL TLSA RRs for a domain's MX hosts one day,
a different MX RRset the next day (e.g. cutting over to an MX
provider) gives no reason to expect TLS on the new MX hosts.

HTTP security is *not* dependent on DNS in the same way,  if you
trust the public CA PKI, the DNS just provides IP addresses, which
must land on a TCP service with the right certificate.  This is
simply not the case with SMTP.

If I am conveying his views correctly, of the things Ben Laurie
likes about HTTP with certificate transparency, is that it is in
fact largely immune to attacks on DNS.  With SMTP, once DNS is
compromised there's not much one can do.

Sure, companies with known high value business partners can configure
static policy enforcing TLS for those destinations, and the current
Postfix TLS policy engine is in large part in support of that model.

The DANE support in Postfix aims to get beyond that scale, to the
Internet at large.  Predicated on the assumption that DNSSEC is
not a dead-end, and will over the next few years see broad adoption,
as management tools and client to registry/registrar interfaces
mature.

-- 
	Viktor.

---

From: Andy Wilson <[email-masked]>
Date: Fri, 6 Sep 2013 14:00:55 +1200

These are very interesting discussions!
Last year I started thinking about email encryption policies and started
writing a RFC; DTSP - Domain-based TLS SMTP Policy.

My thinking was to have a policy record (similar to DMARC) which specified
encryption types for sending and receiving domains; enforcing STARTTLS
basically.

If anyone is interested I can share what I was working on.

-- 
Regards

Andy

---

From: James Cloos <[email-masked]>
Date: Fri, 06 Sep 2013 09:17:20 -0400

>>>>> "IF" == Ian Fette (イアンフェッティ) <[email-masked]> writes:

IF> Let's say that you want to know a-priori if an email will be sent over TLS.

IF> (2) gives you a signal that you could potentially pass on to a user,
IF> and then the user can potentially make a decision about whether or
IF> not they want to send the email.

The idea of using the existence of an unsecured tlsa rr as a hint that
tls must be used was, IIRC, discussed in the early days of this wg.

There wasn't consensus to include that -- or anything dealing with
unsecured rr sets -- in the rfc due (again, IIRC) to the ease with
which a mitm also can mitm the dns.

Doing MX+TLSA queries as soon as the destination(s) are known so as to
indicate the possibility of TLS (Trusted, Untrusted or Verified) can be
a good idea.

There is a risk of leaking information when the client is not the same
system which will do the outgoing smtp, though, so the lookups may need
securely to be proxied, depending on how the mail is to be submitted.

But it tlsa existance is to be the key, it does seem best to demand that
it be secured.

But please do publish the tlsa sooner rather than later.  Even though
they likely will not get used in practice until the zones are signed,
tests can still be done to ensure accuracy, and there won't have to be
any delays post-signing.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Sep 2013 15:50:16 +0000

> tls must be used was, IIRC, discussed in the early days of this wg.

This is largely impractical for SMTP.  SMTP TLSA RRs are of course
tied to MX hosts (transport destinations), not email domains.  An
MITM can bypass any such cached RRs by sending malicious MX replies.

The TTLs on MX records are often relatively short (gmail.com is 1H)
so attacks don't require the attacker to wait long and for smaller
destination domains which don't receive a steady stream of traffic
from all senders, or when intercepting a low-volume sender, the
target MX RRset is often already expired from the cache due to
infrequent mail transmission.

Also any insecure data with a remotely specified TTL is a golden
opportunity for cache poisoning attacks.  Just set a very long TTL
with a bogus certificate association and the MITM attacker is set
for a long time.  In the mean time log entries show happily
authenticated connections, nobody is any the wiser unless they are
logging the underlying digests and looking for malicious changes.

I understand that it would be convenient if security could be
obtained more easily.  Sadly, there is a lower bound on the cost.

> indicate the possibility of TLS (Trusted, Untrusted or Verified) can be

What should an MTA do differently when insecure TLSA records are
found for one or more MX hosts, and why?

> But it tlsa existance is to be the key, it does seem best to demand that

On this we agree.

> tests can still be done to ensure accuracy, and there won't have to be

A better test is to use non-production MX hosts in a signed zone.

	dane-test.gmail.com. IN MX 0 mx.dane-test.gmail.com.
	mx.date-test.gmail.com. IN A 192.0.2.1
	mx.date-test.gmail.com. IN TLSA 2 1 1 {sha256 pubkey hash}

then one can test verified connections to dane-test.gmail.com before
publishing TLSA RRs for the production zone.

-- 
	Viktor.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 6 Sep 2013 09:12:08 -0700

That would assume deploying dnssec on Gmail.com is somehow easier than on
Google.com :-)

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Sep 2013 17:39:19 +0000

> That would assume deploying dnssec on Gmail.com is somehow easier than on

Sorry if I was unclear.  My example was about testing TLSA in a
signed zone on non-production TLS endpoints before publishing for
the first time on production endpoints.  No intent to imply that
any particular domain is an easier place to do DNSSEC.

In the specific case of gmail.com, you'd need DNSSEC on both gmail.com
and google.com:

    $ dig +short -t mx gmail.com | sort -n
    5 gmail-smtp-in.l.google.com.
    10 alt1.gmail-smtp-in.l.google.com.
    20 alt2.gmail-smtp-in.l.google.com.
    30 alt3.gmail-smtp-in.l.google.com.
    40 alt4.gmail-smtp-in.l.google.com.

since not only the gmail.com MX RRset needs to be secure, but also
the zone containing the actual MX hosts, since these are the TLSA
base domains.

I am guessing that one the major obstacles to DNSSEC for Google is
all the interaction with DNS geo load-balancing gear.  I don't know
whether there is gear of that ilk that supports DNSSEC, or whether
beyond the hardware there are architectural obstacles to DNSSEC in
combination with highly dynamic DNS responses.

It may take some time for Google to publish TLSA RRs in a signed
zone, but it is I hope worth the effort to figure out what the
obstacles are and what it would take to address them.

In the mean time Google can easily add client-side DANE TLSA support,
this just requires a DNSSEC aware resolver.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Sep 2013 18:36:41 +0000

> this just requires a DNSSEC aware resolver.

Plus of course very carefully written DANE-aware peer-chain
verification code in the SMTP client.  Some implementations
forget to properly check the validity of usage "2" chains
(that each element is unexpired, signed by its parent, ...).

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 06 Sep 2013 22:12:38 -0400

>> tls must be used was, IIRC, discussed in the early days of this wg.

VD> This is largely impractical for SMTP.  SMTP TLSA RRs are of course
VD> tied to MX hosts (transport destinations), not email domains.  An
VD> MITM can bypass any such cached RRs by sending malicious MX replies.

I was noting history above, not advocating.

I also wrote the the wg consensus was against using unsecured TLSA (or
other new RRs) for anything.

I always preferred dnssec-for-everything-dane.

-JimC