reply inline
On Thu, Sep 5, 2013 at 5:23 PM, Viktor Dukhovni <[email protected]>wrote: > 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. > Presumably T-Online, web.de and GMX believe that by indicating to a user a-priori whether their email will be sent over an encrypted channel, that the user will make some decision. (See http://www.e-mail-made-in-germany.de/Kennzeichnung.html) - so there is potentially an opportunity for a user decision. > > 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. > Wouldn't this argument make DNSSEC less important, if you believe that the MTA-MTA connection is less susceptible to MITM? > > 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. > I don't know if I would say "no need". We would like to send email only over TLS if we know the other end is TLS aware. Unfortunately, it's difficult to determine if someone is experimenting with TLS on some of their hosts (some servers seem to sporadically advertise STARTTLS and it's not clear if they expect it to be 100% or if they're experimenting), or whether they would expect us to hard fail. I'd love to be able to say to a host "If you do X, we will consider the absence of STARTTLS in your EHLO response to be a critical error and bounce the message". > > > 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. > Yes, which is why I would like a way to signal something more permanent and noticeable than the context of a single SMTP connection. I'd be fine putting a 1 week TTL on a TLSA record; yes it's possible that someone attempts DNS cache poisoning though this is perhaps a bit more difficult with a larger TTL. > > > 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). > It's something we're considering among other options, though it's difficult for us to expect others to deploy this if we ourselves can't deploy it. > > > 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. > Depends on what you tie HSTS to. In the HTTP case, the HSTS indication is "Thou shalt connect to xyz.com over HTTPS". The TTL of that indication is divorced from the TTL of the A record for xyz.com. > > > 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. > I would love that, but I would also love something I could deploy sooner than Warren, Ben and others are likely to be able to deploy dnssec for google.com :) > > > 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. > We already do (and even offer a valid certificate, no less). We'd like to do more. Hence this massive email thread :) > > 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. > You say SMTP security is not possible without DNS security. One could say the same thing about HTTP security and yet that has not stopped us from making improvements in that area (be they HSTS, certificate pinning, certificate transparency, or any number of other attempts at making incremental improvements without relying on DNSSEC deployment.) > > > 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. > Agreed, unfortunately I can't satisfy all of its prerequisites at the present point in time. > > It is tempting to apply lessons learned in browser security to > SMTP, but many don't carry over. > > I agree. And FWIW, I also agree with most of your points here about deploying without DNSSEC leaving vulnerabilities open, some of which you have enumerated. However, I've yet to hear a good argument for why one would ignore information not protected by DNSSEC. In the case of a TLSA record for HTTPS/443 I understand, I don't understand why one would ignore that information for SMTP/25. > -- > Viktor. > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
