Subject: Re: [TLS] [Cfrg] 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: Geoffrey Keating <[email-masked]>
Date: 20 Mar 2013 22:06:56 -0700

> >it causes compatibility issues and the motivation hasn't previously been
...
> It causes compatibility problems, but I can't think
> of any pressing issue that it solves apart from "we need to do Suite
> B".
...

It also lets you do GCM, which has performance benefits over AES+SHA1.

Part of the reason TLS 1.2 doesn't solve issues is because people were
willing to go to great lengths to avoid going to a higher TLS version,
even in cases where a new version would be the obvious and simplest
choice, the zero-size record hack and renegotiation cipher
suite/extension being two examples that come to mind.  So are we now
in a catch-22 where no-one will upgrade because they don't need to
because all the fixes are shoehorned into the current version because
no-one will upgrade?

---

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: Adam Langley <[email-masked]>
Date: Thu, 21 Mar 2013 08:18:11 -0400

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

But you don't need to switch on TLS 1.2 to fix this, right? The server
just needs to implement version negotiation correctly.

(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

---

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

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

> Email secured by Check Point

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 Mar 2013 06:23:12 +0100 (CET)

Adam Langley wrote:
> > 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.

Are you sure?

It would clearly be stupid behaviour on part of iPhone to send an
initial ClientHello with { 0x03, 0x03 } at the record layer.

It should be sending this version in ClientHello.client_version alone.
 
> just needs to implement version negotiation correctly.

The servers typically implement it correctly.  If iPhone is willing
to talk a protocol version < TLSv1.2, then using TLSv1.2 on the
Record Layer on the first ClientHello is a stupid bug. 

Only(!!) TLSv1.2 servers will ignore the record layer PDU version
on the initial ClientHello (but for them this is currently entirely
irrelevant, since there is no TLSv1.3 and no borked TLSv1.3 clients
that tag PDUs incorrectly).

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 Mar 2013 06:06:44 +0000

> initial ClientHello with { 0x03, 0x03 } at the record layer.

It would be, and it was. This was long ago, so it may have been fixed in iOS 6.

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 22 Mar 2013 10:30:32 -0700

> It should be sending this version in ClientHello.client_version alone.

The TLS 1.2 spec. clearly allows for this 'stupid' behavior.  Here's an
excerpt from RFC 5246 Appendix E (Backward Compatibility):

    Earlier versions of the TLS specification were not fully clear on
    what the record layer version number (TLSPlaintext.version) should
    contain when sending ClientHello (i.e., before it is known which
    version of the protocol will be employed).  Thus, TLS servers
    compliant with this specification MUST accept any value {03,XX} as
    the record layer version number for ClientHello.

    TLS clients that wish to negotiate with older servers MAY send any
    value {03,XX} as the record layer version number.  Typical values
    would be {03,00}, the lowest version number supported by the client,
    and the value of ClientHello.client_version.  No single value will
    guarantee interoperability with all old servers, but this is a
    complex topic beyond the scope of this document.

Perhaps some better advice should be added next time ("use the client's
lowest supported version") and placed in the main document instead of
an appendix....

Mike

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 22 Mar 2013 10:49:54 -0700

> lowest supported version") and placed in the main document instead of

As RFC 5246 Appendix E says, this is a complex topic.

We encountered one server that supports SSL 3.0 and TLS 1.0 and
chooses the version in the record layer, ignoring ClientHello.client_version:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.207&mark=2379-2386#2379

If you put the lowest version number supported by the client,
which is typically SSL 3.0 {03, 00}, in the record layer, this
server will pick SSL 3.0, even though it can also do TLS 1.0.

In our experience with the Google Chrome browser, putting
TLS 1.0 {03, 01} in the record layer of the initial ClientHello
has worked well. (ClientHello.client_version is TLS 1.1 {03, 02}
for Google Chrome.)

Wan-Teh

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 Mar 2013 21:13:07 +0100 (CET)

Wan-Teh Chang wrote:
>
> Michael D'Errico <[email-masked]> wrote:
> >

{03, 01} should be interoperable with any server that implements
TLSv1.0, plus those SSLv3 servers where this was retroactively relaxed.

The exact wording rfc5246 is a silly excuse for stupid behaviour
based on a minor typo in rfc2246 that should have been obvious
to every careful implementor.

http://tools.ietf.org/html/rfc2246#appendix-E

   TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
   is easy. TLS clients who wish to negotiate with SSL 3.0 servers
   should send client hello messages using the SSL 3.0 record format and
   client hello structure, sending {3, 1} for the version field to note
   that they support TLS 1.0. If the server supports only SSL 3.0, it
   will respond with an SSL 3.0 server hello; if it supports TLS, with a
   TLS server hello. The negotiation then proceeds as appropriate for
   the negotiated protocol.

Question: what is the difference between "SSL 3.0 record format"
and "TLS 1.0 record format"?  If they had meant to use the the
TLSv1.0 record format for a backwards compatible ClientHello, this
text wouldn't have been there.

2nd Question: what is the version field of the client hello structure?

The protocol version field at the Record Layer declares the version
of the protocol PDU.  An implementation of a particular protocol
version should not make any flawed assumptions about future protocol
versions which it does not implement and simply reject them.

For example, an implementation of SSLv3 or TLSv1.0 will typically
not be able to parse a TLSv1.1 "GenericBlockCipher" PDU or
TLSv1.2 CertificateRequest or TLSv1.2 ServerKeyExchange or
TLSv1.2 CertificateVerify PDUs, because these differ from
earlier protocol versions.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 23 Mar 2013 02:46:40 +0100 (CET)

> excerpt from RFC 5246 Appendix E (Backward Compatibility):

Yes, I know.  The text in rfc5246 (TLSv1.2) is a poor solution,
trying to make broken TLS implementation look less broken
than they really are.

Since TLSv1.2 servers(!) are finally required to accept any {03,XX}
record version for the initial ClientHello, it is UNREASONABLE for a
client to use TLSv1.2 {03,03} at the record layer _unless_ the
client is not willing to talk any lower protocol versions.
And this is what the text in rfc5246 fails to point out!

We had the discussion in 2006.
I started a discussion thread about it here:

  http://www.ietf.org/mail-archive/web/tls/current/msg00677.html

One of Pasi's later replies:
  http://www.ietf.org/mail-archive/web/tls/current/msg00684.html

rfc2246(TLSv1.0) says that you should use SSLv3 record format for
a handshake with a SSLv3 server, and TLSv1.0 in the ClientHello structure.

rfc4346(TLSv1.1) says that you should use SSLv3 record format for
a handshake with a TLSv1.0 or SSLv3 server and a TLSv1.1 in the
ClientHello structure.

Bodo is reading the spec correctly (excerpt):
  http://www.ietf.org/mail-archive/web/tls/current/msg00681.html

   The specification specifically demands the "SSL 3.0 record format and
   client hello structure", which is essentially the same as the TLS 1.0
   record format and client hello structure, with the notable exception
   of the version number field.  So it's quite clear that you should put
   {03,00} into the record header version field, since this is the only
   way you can actually avoid the "TLS 1.0 record format" and use the
   "SSL 3.0 record format".  On the other hand, this could trigger some
   bugs in thoughtlessly done server implementations, which are avoided
   by sending {03,01} in the record version field.

Robert Dugal's comment is also reading the spec correctly:
   http://www.ietf.org/mail-archive/web/tls/current/msg00683.html

   Bodo Moeller <bmoeller at acm.org> wrote on 07/04/2006 05:41:06 AM:
   >  Pasi.Eronen at nokia.com wrote:
   >
   > > A quick and totally unscientific survey of what some widely used
   > > SSL/TLS implementations do:
   > >
   > > - OpenSSL (0.9.8)
   > >   - When configured in "both SSLv3 and TLSv10 allowed" mode,
   > >     sends V2 ClientHello.
   >
   > This is the behavior of OpenSSL versions up to 0.9.7g.  Versions
   > 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3
   > format Client Hello message with version number {03,01} in both
   > fields.  

   The 0.9.8 behavior doesn't make sense to me. I think the correct
   behaviour would be to encode the minimum protocol {03,00} in the
   record's protocol field and the highest protocol {03,01} in the
   client_hello message's protocol field. A server that understands
   only SSLv3 could reject a client hello message that uses a record
   protocol of TLSv1. To negotiate with an SSLv2 server the client
   must send an SSLv2 client hello so why would the situation be any
   different for SSLv3/TLSv1? 

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 15:43:11 +0100 (CET)

> has worked well. (ClientHello.client_version is TLS 1.1 {03, 02}

When we discussed that issue on the TLS WG mailing list in 2006, there
was already quite some variation around, and there was a significant
amount of implementations in the installed base sending TLSv1.0 in
record layer and ClientHello.client_version, and this specific
combination had at least the same interoperability as SSLv3 in record
layer and TLSv1.0 in ClientHello.client_version.

I can understand that one does not want to retroactively patch a
change of behaviour of the installed base unless there are interop
benefits (which there were not apparent for {03,00}+{03,01} over
{03,01}+{03,01}.  But what should have been obvious is that it would
be a bad idea to make the situation any worse going into the future.

Google Chrome (25) improved, sending {03,01}+{03,02}
OpenSSL-1.0.1c improved, sending {03,01}+{03,03},

Microsoft Windows 7 is worse than 2006, sending {03,03}+{03,03},
similar to iPhone...

-Martin