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

[Viktor Dukhovni <[e-mail]>]

On Fri, Sep 06, 2013 at 09:17:20AM -0400, James Cloos wrote:

> 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.

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.

> 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.

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
> it be secured.

On this we agree.

> 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.

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.