Subject: [TLS] incompatibilities with ECC rfc

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 17 Mar 2012 14:04:11 +0100

Hello,
 I noticed today that gnutls isn't interoperable with openssl with the
elliptic curve ciphersuites [0]. In particular the ECC document says
"This document describes additions to TLS to support ECC, applicable
both to TLS Version 1.0 [2] and to TLS Version 1.1 [3].  In particular,
it defines...".

My understanding of it is that SSL 3.0 shouldn't be used with ECC
ciphersuites, but it seems openssl as a server negotiates them under SSL
3.0. What is the behavior of other implementations? Should it be
that similar version restrictions in this and other drafts be
ignored?

By the way the ECC draft doesn't mention TLS 1.0 or later, and if taken
literally it means that these ciphersuites are not to be used in TLS 1.2.

regards,
Nikos

[0]. http://tools.ietf.org/html/rfc4492

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Mar 2012 08:05:28 -0700

> that similar version restrictions in this and other drafts be

SSL 3.0's use of the cipersuites is undefined in RFC 4492.

> literally it means that these ciphersuites are not to be used in TLS 1.2.

Not true. TLS 1.2 (RFC 5246) explicitly updates RFC 4492, both in the boilerplate at the top of the RFC and in Appendix A.7.

--Paul Hoffman

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 17 Mar 2012 21:33:43 +0100

> SSL 3.0's use of the cipersuites is undefined in RFC 4492.

This is my reading of the document as well, but it seems that this
interpretation is not universal and for good reasons.

For example rfc4132 adds new ciphersuites to TLS 1.0. Should they be
used under SSL 3.0 or not? I say not, but it can be claimed that there
is no good reason not to use these ciphersuites under SSL 3.0 [0].

What do we do then? Live with interoperability issues?
Have other implementations run into it and handled it somehow?

regards,
Nikos

[0]. http://marc.info/?l=openssl-dev&m=133200238929226&w=2

---

From: Marsh Ray <[email-masked]>
Date: Sat, 17 Mar 2012 16:09:05 -0500

> is no good reason not to use these ciphersuites under SSL 3.0 [0].

SSL 3.0 isn't a standard maintained by the IETF TLS WG (or by anybody 
for that matter). So nobody can say what SHOULD be done with it.

(OK maybe that's not strictly true, RFC 6176 says TLS clients and 
servers MUST NOT use SSL 2.0 but I don't think there are any RFCs that 
are directly prescriptive about how SSL 2.0 or 3.0 should behave if its 
use is negotiated.)

> Have other implementations run into it and handled it somehow?

For the record, I suppose the official answer would be: use TLS 1.0 or 
higher.

I realize you may be testing the corner case explicitly, but really, are 
there any implementations that speak RFC 4132 ciphersuites but *don't* 
speak TLS?

There's probably a server or two in the wild configured that way but it 
doesn't seem like a good idea to me.

The Qualys survey 2 years ago 
http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf 
found only 0.05% of servers that had SSL 3.0 as the highest supported 
protocol (none were found to only do SSL 2.0).

Perhaps it would be a good idea for server implementations to strongly 
de-prioritize or ignore entirely the RFC 4132 and newer ciphersuites for 
handshakes that negotiate the use of SSL 3.0.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Sat, 17 Mar 2012 23:41:46 +0200

> there any implementations that speak RFC 4132 ciphersuites but *don't* 

Probably not. But there's also few if any web browsers that don't speak SSLv3. Most browsers will begin the SSL handshake at version 3.0 and indicate support in the ClientHello Version field for TLS 1.0 or 1.2 (everyone who's implemented 1.1 has implemented 1.2 by now). The same ClientHello that negotiates versions also negotiates ciphersuites, so the client offers SSLv3 and an ECC ciphersuite at the same time. It has to be ready for the case where the server replies at SSLv3, and chooses the ECC ciphersuite.

We could decide that this is wrong, goes against the RFC, and the client should abort with some alert. I just don't see any reason why a client should do so.

As for the server, it should choose the highest TLS version supported by it and the client. It's fairly unreasonable that this will be SSLv3 if an ECC ciphersuite is being offered and understood. The client should be ready for this.

.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Mar 2012 14:51:18 -0700

> Probably not. But there's also few if any web browsers that don't speak SSLv3. Most browsers will begin the SSL handshake at version 3.0 and indicate support in the ClientHello Version field for TL…

Could you explain what you mean by "begin the SSL handshake at version
3.0"? You indicate
the highest version you support (and nothing else) in the ClientHello.
So you're not offering
SSLv3--the server has no idea if you would accept it, and indeed if
the server chooses
it you are free to reject it.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Mar 2012 09:14:56 +0200

3.0 in the TLS header
3.1/3.3 in the ClientHello

3.1/3.3 are the highest version you support, but you can obviously accept SSLv3, because of the TLS header 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: 17 March 2012 23:51
To: Yoav Nir
Cc: Marsh Ray; [email-masked]
Subject: Re: [TLS] incompatibilities with ECC rfc

On Sat, Mar 17, 2012 at 2:41 PM, Yoav Nir <[email-masked]> wrote:
>> For the record, I suppose the official answer would be: use TLS 1.0 
>> or higher.
>>
>> I realize you may be testing the corner case explicitly, but really, 
>> are there any implementations that speak RFC 4132 ciphersuites but 
>> *don't* speak TLS?
>

Could you explain what you mean by "begin the SSL handshake at version 3.0"? You indicate the highest version you support (and nothing else) in the ClientHello.
So you're not offering
SSLv3--the server has no idea if you would accept it, and indeed if the server chooses it you are free to reject it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2012 08:06:11 -0700

Well, the record header isn't used for negotiation. So while RFC 5246;
S E.2 does
in fact recommend this practice, there's no requirement that a client which
sends the 3.0/3.x pair actually supports the range 3.0-3.x.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2012 20:13:49 +0100 (MET)

Eric Rescorla wrote:
> S E.2 does in fact recommend this practice, there's no requirement that
> a client which sends the 3.0/3.x pair actually supports the range 3.0-3.x.

The protocol version in the TLS record header describes the version
of the protocol for that particular PDU.

A client that sends { 0x03, 0x00 } in the TLS record protocol for the
records conveying the ClientHello is actively indicating that it has
implemented SSLv3.

   version
       The version of the protocol being employed. 

This does _not_ indicate, however, that the client will agree to
negotiating SSLv3 for the connection.  Depending on client policy or
configuration, the client may be offering { 0x03, 0x03 } as his highest
supported client_version within ClientHello and abort if the server
does not choose at least { 0x03, 0x01 } TLSv1.0 for his ServerHello
response.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2012 20:23:22 +0100 (MET)

> that similar version restrictions in this and other drafts be

Why should there be a limitation of ECC to TLS?  That would have the
prerequisite of partitioning the cipher suite number range to cipher
suites that are TLS only and a range that can be used with SSLv3.
It is quite possible that disabling ciphersuites for use with SSLv3
(instead of letting them just work) would require additional code,
so adding such code hardly makes sense.

There seem to be similar interop issues with AES ciphersuites (rfc3268),
which work fine in Firefox with SSLv3, but Microsoft's Channel
does not support them with SSLv3.

-Martin

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 19 Mar 2012 17:37:02 -0700

> that similar version restrictions in this and other drafts be

Since the ECC ciphersuites require the use of the Supported Point
Formats extension, it would be difficult to use them with SSL 3.0
since most SSL 3.0 implementations don't support extensions.

In any case, with widespread deployment of TLS, I agree with Marsh Ray
that this is a corner case that should only happen when the server is
misconfigured to turn off TLS.

In NSS, AES and Camellia cipher suites can be used in SSL 3.0, but ECC
cipher suites can't because of the extension issue.

Wan-Teh

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2012 17:57:20 -0700

On Mar 19, 2012, at 12:23 PM, Martin Rex wrote:

> Why should there be a limitation of ECC to TLS?  

Because that is how the document describing how to do ECC defined it, and that is how the document was evaluated. If you believe that RFC 4492 should be updated to also cover other versions of TLS, it should be quite simple to generate a one-page draft, and if there is no technical problem, it should sail through.

> does not support them with SSLv3.

Ditto.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Mar 2012 13:49:49 +0200

> does not choose at least { 0x03, 0x01 } TLSv1.0 for his ServerHello

That would be a strange way to deploy the client. Why would it send 0x03,0x00 if it doesn't agree to negotiate it? In that case it should send 0x03,0x01 in the TLS header.

I understand why a server would accept an SSLv3 or even SSLv2 header when it won't accept them as the negotiated version for the connection, but I fail to see why that would be a good idea for a client.

Yoav

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 20 Mar 2012 15:14:49 +0100

> SSL 3.0 isn't a standard maintained by the IETF TLS WG (or by anybody for
> that matter). So nobody can say what SHOULD be done with it.
>

That's my interpretation too.  Any "SSL 3.0" implementation is based on an
ad-hoc interpretation of a bunch of specs (or, worse, is following the
historical SSL 3.0 specification by the letter).  If both the client and
the server do support any version of TLS, then they won't be negotiating
use of SSL 3.0 anyway.  If they negotiate a non-IETF protocol, we can't
expect IETF specifications to have all the details on how that protocol
works.  Generally, this shouldn't be relevant -- SSL 3.0 is historic, so
implementations that don't support TLS but do support a new ciphersuite are
somewhat unexpected.

(Specifically for the ECC ciphersuites, these normally do involve TLS
extensions, which aren't defined for SSL 3.0, so RFC 4492 couldn't just
have said that the ECC ciphersuites work exactly the same for SSL 3.0.)

Bodo

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 20 Mar 2012 18:27:18 +0100

On 03/20/2012 03:14 PM, Bodo Moeller wrote:

> use of SSL 3.0 anyway.  

The TLS 1.0 protocol is designed in a way to interoperate with SSL 3.0
as well as SSL 2.0 (we even have an SSL 2.0 compatible hello). Thus
interoperability issues with SSL 3.0 are within the scope of the WG clearly.

However the issue isn't on SSL 3.0, but on the RFCs in question. Are
the TLS numbers mentioned hard limits? Implementations MUST follow them,
or MAY follow them?

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 20 Mar 2012 19:01:32 +0100

On Tue, Mar 20, 2012 at 6:27 PM, Nikos Mavrogiannopoulos <[email-masked]>wrote:

> interoperability issues with SSL 3.0 are within the scope of the WG

How to **support** SSL backwards-compatibility within a TLS handshake
clearly is within the scope (if TLS servers don't accept your
backwards-compatible client hellos, you can't try to interoperate with SSL
servers), but once a client and server have **actually** negotiated SSL,
that's a different matter.

> the TLS numbers mentioned hard limits? Implementations MUST follow them,

As one data point, the TLS Extensions RFCs (RFC 3546, RFC 4366, RFC 6066)
don't mention SSL at all, but RFC 5746 (TLS Renegotiation Indication
Extension) assumes that you'd use extensions exactly similarly with SSL 3.0.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Tue, 20 Mar 2012 13:18:27 -0500

On 03/20/2012 01:01 PM, Bodo Moeller wrote:
> As one data point, the TLS Extensions RFCs (RFC 3546, RFC 4366, RFC
> 6066) don't mention SSL at all, but RFC 5746 (TLS Renegotiation
> Indication Extension) assumes that you'd use extensions exactly
> similarly with SSL 3.0.

RFC 5746 was developed with the primary goal of getting a solid bugfix 
out as quickly as possible to as many vulenerable systems as possible. 
Compatibility with the installed base, even of some nonstandard and 
noncompliant servers, was an overriding concern because it could delay 
adoption.

There was a lot of discussion over how it could be made to benefit SSL 
3.0 implementations too; the SCSV is an example of that. But in this 
regard I wouldn't hold up RFC 5746 as a model of recommended policy!

It is data point though.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Mar 2012 21:53:05 +0100 (MET)

Yoav Nir wrote:
> That would be a strange way to deploy the client.
> Why would it send 0x03,0x00 if it doesn't agree to negotiate it?
> In that case it should send 0x03,0x01 in the TLS header.
> 
> I understand why a server would accept an SSLv3 or even SSLv2 header
> when it won't accept them as the negotiated version for the connection,
> but I fail to see why that would be a good idea for a client.

One motivation for a client to do this would be to get back a comprehensible
server reply rather than a simple closure of the network connection.  There
are TLS peers (pretty much all that run on top of Microsoft SChannel),
that do _not_ send TLS Alerts before closing the network connection
when encountering a problem.

In principle I agree with you that sending the lowest supported
protocol version is in theory a good choice.

This question comes up every now and then.  :)

e.g.:

  https://www.ietf.org/mail-archive/web/tls/current/msg05673.html

and the end of this message:
  https://www.ietf.org/mail-archive/web/tls/current/msg07653.html

-Martin