RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt

<Pasi.Eronen@nokia.com> Mon, 03 July 2006 16:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxR4K-0001fB-5O; Mon, 03 Jul 2006 12:14:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxR4I-0001ev-Mh for tls@ietf.org; Mon, 03 Jul 2006 12:14:38 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxR4I-0000fp-5t for tls@ietf.org; Mon, 03 Jul 2006 12:14:38 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k63GEZB1021150; Mon, 3 Jul 2006 19:14:37 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 19:14:19 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 19:14:18 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Date: Mon, 3 Jul 2006 19:14:15 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402D9BF00@esebe105.NOE.Nokia.com>
In-Reply-To: <200607031523.RAA09074@uw1048.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Thread-Index: AcaetMoHc3D/fCTQTwK+uYQnnNSJjAABMZ2Q
From: <Pasi.Eronen@nokia.com>
To: <martin.rex@sap.com>, <tls@ietf.org>
X-OriginalArrivalTime: 03 Jul 2006 16:14:18.0529 (UTC) FILETIME=[BC812110:01C69EBB]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Hi Martin,

I agree that the spec is ambiguous in this respect, but I'm not
so sure about what the correct interpretation should be. In 
other words, when a TLS client supports more than one of (SSLv3,
TLSv10, TLSv11), should the record layer version number contain
the lowest supported protocol, or the same value as handshake
layer ClientHello?

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.
  - When configured in "TLS10 only" mode, sends {03,01} in both fields
- Mozilla Firefox 1.5
  - Seems to send V2 ClientHello no matter what the settings??
- MS Internet Explorer 6.0
  - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
    sends V3 ClientHello with {03,01} in both fields
- SunJSSE (JDK 1.4.2)
  - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
    sends V3 ClientHello with {03,01} in both fields
- GnuTLS (10.0.20)
  - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
    sends V3 ClientHello with {03,01} in both fields
  - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode,
    sends V3 ClientHello with {03,02} in both fields

In other words: All these implementation seem to follow the
rule that TLSPlaintext.version==ClientHello.client_version, or
use V2 ClientHellos...

Given that Yngve's interoperability draft suggests that some
servers incorrectly use the record layer version number for
negotiation, I think the safest clarification would be to 
say that the two version numbers must be equal.

Best regards,
Pasi

> -----Original Message-----
> From: ext Martin Rex [mailto:martin.rex@sap.com] 
> Sent: 27 June, 2006 23:39
> To: tls@ietf.org
> Subject: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
> 
> 
> While privately discussing I-D 
> draft-pettersen-tls-interop-experience-00.txt
> I came across what I consider a potential ambiguity in TLS 
> v1.0 (rfc2246)
> and TLS v1.1 (rfc4346):
> 
> 
> Appendix E "Backward Compatibility With SSL" 2nd paragraph says this:
> 
>    TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, 
> supporting
>    both is easy. TLS clients who wish to negotiate with such older
>    servers SHOULD send client hello messages using the SSL 3.0 record
>    format and client hello structure, sending {3, 2} for the version
>    field to note that they support TLS 1.1. If the server 
> supports only
>    TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 
> server hello;
>    if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
>    The negotiation then proceeds as appropriate for the negotiated
>    protocol.
> 
> It should read instead
> 
>    ...
>    servers SHOULD send client hello messages using the SSL 3.0 record
>    format and client hello structure, sending {3, 2} for the 
> client_version
>                                                              ^^^^^^^
> 
> because it ought to refer to the Protocol version field in the
> ClientHello message, and *NOT* the version field in the record layer.
> 
> The comment in the OpenSSL code suggests that the Netscape 6.0 browser
> was the first defective SSL client to incorrectly use a {3, 1}
> version tag on the record protocol for the initial client hello,
> but it could be that others have copied this bug.
> 
> Microsoft appears to be shipping a new variant of the bug with IIS,
> which erroneously sends the {3,1} tag in the record protocol when
> forcing an SSLv3 client through renegotiation in order to ask for
> an SSL client certificate _after_ reading the HTTP request over
> an anonymous SSL-client connection--which is kind of odd since
> the session is fully established as 3.0 and the Server Hello
> correctly contains 3.0...
> 
> 
> Btw.  all previous TLS documents increased the TLS protocol version
> in Appendix A.1.1 / A.1, draft-ietf-tls-rfc4346-bis-01.txt hasn't
> yet done so.
> 
> 
> The ProtocolVersion tag on the SSL/TLS record protocol defines
> the encoding of the PDU, and therefore older implementations
> ought not even try to parse PDUs which they can not be expected to
> understand/recognize.
> 
> 
> Regards,
> -Martin
>  
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls