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

[Daniel Kahn Gillmor]

On Thu 2015-07-30 06:17:16 -0400, Kim Alvefur wrote:
> tors jul 30 06:21:28 2015 GMT+0200 skrev 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.
>
> Only SNI and the server certificate are both sent in the clear, so
> it's no difference in security.

SNI and server certificate are both about server identity, and not about
targeted XMPP domain or SMTP client hostname.  This is additional
leakage.

Even if they offered the same leakage as SNI and server certificate, in
TLS 1.3 the server certificate will be sent encrypted by a handshake
key, and i'm continuing to push on making it possible to protect SNI
From at least a passive attacker (though this will probably not be the
default mode, unfortunately).

There are also leaks in the DNS when some of these details are looked
up, but we're working on closing those leaks in discussions around DNS
privacy [0], which i invite people to join in.

My point here is that even if there is some other mechanism providing a
similar leak, we should not use that as an excuse or justification for
more leakage.  We can fix existing leaks, and we need to do so.  "Don't
bother fixing X because Y also breaks the same thing" is conveniently
symmetric. It can be used to justify arbitrary claims of "Don't fix X".

Rather, we should be asking "How can we fix X, so that we can increase
the pressure to also fix Y?"  And we certainly should not condone the
creation of additional metadata leakage without strong justification
that takes into account the tradeoff.

         --dkg

[0] https://datatracker.ietf.org/wg/dprive/documents/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.cert.at/pipermail/ach/attachments/20150730/39ece86c/attachment.sig>