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

[Paul Hoffman <[e-mail]>]

On Feb 14, 2014, at 2:50 PM, James Cloos <[e-mail]> wrote:

> The only real question is whether dane-srv and dane-smtp-with-dane
> should be published as two rfcs or combined into one?
> (I’m leaning towards two, numerically adjacent.)

With all due respect, there are other real questions, much more significant than that one.

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.

Viktor's view gives us good MITM protection if the DNS channel is not broken and the client knows the DNSSEC status of its query. It also causes messages to be lost if there is an operational problem or even an unexpected mis-match on the crypto desires of the client and server. It also assumes that the person running the DNS server for a name is in active contact with the person operating the SMTP server.

Personally, I don't care about MITM protection if it comes at the cost of getting more organizations to turn on opportunistic crypto. I think DANE still has an important role in that it gives the SMTP server operator a logging capability to see if there is an MITM. Others prefer more protection against MITMs even in the face of preventable communication failures.

And, to be blunt, if we think that Viktor is right about DANE for SMTP, shouldn't DANE for HTTP have the same MITM protection and operational downsides?

--Paul Hoffman