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

[Viktor Dukhovni <[e-mail]>]

On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote:

> Personally, I don't care about MITM protection if it comes at
> the cost of getting more organizations to turn on opportunistic
> crypto.

One quick comment, there is no conflict between opportunistic DANE
TLS and "pre-DANE" opportunistic TLS.  So I would take issue with
"at the cost of".  If anything the two are symbiotic.

The first step for an SMTP server operator towards greater channel
security is to enable STARTTLS if they have not already done that.
At that point all TLS-enabled clients (be they DANE aware or not)
will generally send email over unauthenticated TLS.

Once the server operator determines that TLS is working satisfactorily
for all clients (observed over weeks to months) he may decide to
enable DNSSEC for his domain and if that works out OK, later publish
a TLSA "3 1 1" RRset that matches his server certificate.  The
certificate will not capriciously expire causing an SMTP outage,
it will only become invalid through explicit removal from the TLSA
RRset (presumably after it is augmented by an RR matching a new
certificate which then replaces the original).

This simplified authentication protocol for SMTP is carefully
designed to avoid most operational pitfalls, and the hope is that
it will be reliable enough to be enabled by default on clients and
stable when deployed with care on servers.

All that aside, the main point is that there is NO conflict between
"pre-DANE" opportunistic TLS and DANE opportunistic TLS.  The latter
is turned on only at the request of the server operator.

As to why MTA to MTA SMTP is more special in this regard than HTTPS,
the main reason is that MTAs don't generally roam into hotels,
internet cafes, and other DNSSEC hostile environments.  Being server
infrastructure MTAs are much less likely to run into MITM false
positives due to shifting network conditions.

-- 
	Viktor.