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

[Viktor Dukhovni <[e-mail]>]

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
> end of the day, what I would like to signal is that servers should expect
> 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
> think of accomplishing this, one being DANE, another being something
> 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
> 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.

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

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.