Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 Mar 2013 04:49:52 +0000

Adam Langley <[email-masked]> writes:
>On Wed, Mar 20, 2013 at 7:53 PM, Jon Callas <[email-masked]> wrote:
> TLS 1.2 needs some marketing that explains why people want it, and that
> needs to include reassurance that it doesn't require you to commit to ECC 
> and GCM. Many people out there believe precisely this.
>
>I believe that the reason that TLS 1.2 hasn't seen wider deployment is that
>it causes compatibility issues and the motivation hasn't previously been
>strong enough.

Exactly.  Getting back to Jon's point that "it needs some marketing that
explains why people want it", I can't think of any reason why you'd want it.
It causes compatibility problems, but I can't think of any pressing issue that
it solves apart from "we need to do Suite B".  This is why it's seen as "TLS
with Suite B", because that's it's sole marketing point.

Look at OCSP pinning as a counterexample.  Virtually every major site deployed
this as quickly as they could, because the site owners recognised that if they
didn't do it, they'd take a significant performace hit or even complete OCSP-
induced site outages (on hard fail).

If you don't deploy TLS 1.2 OTOH, nothing happens.  You're no slower, no less
available, no less secure... the only thing you don't have is Suite B.  I
implemented it some time ago and so far the sole users have been (a) a small
number of users who wanted Suite B and (b) an even smaller number of users,
mostly in Europe, who insisted on having the largest version number of TLS
they could get.  Most of the latter went back to 1.1 when they started running
into problems with interoperability.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Mar 2013 12:09:25 +0000

> into problems with interoperability.

Actually, we turned on TLS 1.2 by default for the speed advantage. iOS begins a TLS handshake with version 1.2, both in ClientHello and in the record layer. Only when the (shocked and flabbergasted) server closes the connection, does the iPhone try with something more sane like 1.0, and then even caches this for a short while.

This takes two extra round-trips.

The bug report said "iPhone x is slow to connect" (I don't remember if at the time x was 5 or 6.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Mar 2013 20:26:21 +0000

On Mar 21, 2013, at 8:18 AM, Adam Langley <[email-masked]> wrote:

> On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir <[email-masked]> wrote:
> But you don't need to switch on TLS 1.2 to fix this, right? The server
> just needs to implement version negotiation correctly.

We consider the record layer version to be the minimum version supported by the client, and the version in the ClientHello to be the maximum version supported by the client. Since both were 1.2, our code concludes that TLS 1.2 is the only supported version. We tried replying in TLS 1.0, and we got a TCP reset or an alert (I forget which). So without TLS 1.2 support, the first connection would always fail. In practice this wouldn't be a problem, because the phone would get the penalty once, and then cache the information that our server doesn't support 1.2. Still, we preferred to add support for TLS 1.2 (which I wanted to do anyway)

> (On the flip side, this /is/ a problem for clients since the
> incentives are aligned for clients to stop trying TLS 1.2 since they
> can't (directly) fix the server.)
> 
> 
> Cheers
> 
> AGL
> 
> Email secured by Check Point