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, 03 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
- [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Martin Rex
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Pasi.Eronen
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Martin Rex
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt David Hopwood
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Bodo Moeller
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Pasi.Eronen
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Rob Dugal
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Pasi.Eronen
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Bodo Moeller
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Rob Dugal