[Ach] implicit TLS vs. STARTTLS [was: Re: Fwd: E-Mail Protocol Security Measurements]

[Daniel Kahn Gillmor]

On Tue 2015-07-28 16:47:49 -0400, Hanno Böck wrote:
> STARTTLS is risky, because there are mail apps out there that will by
> default use "STARTTLS if available". That means they'll do STARTTLS,
> but if the server doesn't support it they'll happily fall back to plain
> text. It's on my "interesting project I could do at some point"-list to
> do a check of famous mail client apps how they behave if you configure
> a starttls connection and then suddenly disable support on the server.
> If anyone wants to take that project feel free :-)

Note also that there are some ISPs that are deliberately doing STARTTLS
stripping :(

 https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks

that said, i think there is no difference in principle between the two
approaches, as long as

  (a) the client side knows whether it should expect TLS and is vigilant
      about enforcing it (i'd love to see someone do Hanno's proposed
      experiment),
      
  and

  (b) the pre-STARTLS handshake leaks no additional metadata about the
      connection.  This is true for IMAP and POP3, but arguably is not
      the case for either SMTP (the initial EHLO leaks its configured
      hostname) or for XMPP (the opening <stream:stream> element's "to"
      attribute leaks the desired xmpp domain, which might vary for
      connections to a multi-tenanted XMPP service).

failures in (b)-style leakage for XMPP and SMTP could be mitigated by
selecting a generic string for the relevant field that any server could
accept as an "i'm about to go to TLS" message.  I don't know if anything
like that has been specified anywhere though.


  --dkg