Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

[Viktor Dukhovni <[e-mail]>]

On Fri, Feb 21, 2014 at 09:42:06AM -0500, Phillip Hallam-Baker wrote:

> > One of the biggest questions that needs to be asked is not whether DANE
> > can be used for opportunistic protocols, because of course it can, but
> > whether DANE can be used to determine whether a server at a domain name
> > "should" be speaking TLS at the time that a client tries to connect. Viktor
> > makes a strong case that it does for SMTP. During the early discussions of
> > TLSA, many people thought it should not.
> 
> I argued for making DANE a security policy protocol at the start. Now you
> are wondering if what you produced works as a security policy protocol. It
> can but the critical mass for adoption is almost certainly too high.
> 
> DNS resource records are cheap. DNS lookups are not cheap.

For the record, my argument for DANE as a "TLS discovery" mechanism
is strongly SMTP-specific.  I make no claims about TLS discovery
in other contexts.

In MTA to MTA SMTP:

    - There is no signficant last-mile problem.  The vast majority of
      MTAs don't globe-trot.

    - SMTP TLS security is opportunistic and sans DANE unauthenticated.
      We're using DANE to make possible an MITM downgrade-resistant
      opportunistic upgrade from cleartext to authenticated TLS.

    - SMTP is not a real-time protocol.

    - SMTP DNS lookups are not significantly latency impacting.
      Were gmail.com, for example, a DNSSEC signed zone, adding
      DANE would change the number of pre-connection DNS lookups
      for gmail.com in Postfix from 6 to 7.  The local resolver
      caches the results ammortizing the cost over multiple
      deliveries.

      In fact gmail.com is not DNSSEC signed, and the SMTP draft
      explicitly suppresses TLSA lookups in zones where MX host
      A/AAAA records turn up "insecure" responses.  Therefore, the
      cost of TLSA lookups for gmail.com with SMTP is currently
      ZERO.

      The main cost of DANE is incurred as soon as one enables a
      DNSSEC-aware recursive resolver on the MTA, whether for DANE
      or just to fend off Kaminsky cache poisoning.  After that
      TLSA is basically free.

Whatever concerns may exist for adding DANE to HTTP, do not apply
to SMTP.  It is somewhat unfortunate that the mindset around DANE
TLSA is so HTTP-centric, since DANE is a much better fit for
protocols other than HTTP.

I plead that we not break DANE for SMTP just because it is perhaps
a questionable fit for HTTP.  If we stay focused on the problem at
hand, the issue is quickly seen to be rather minor.

-- 
	Viktor.