[TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Martin Rex <martin.rex@sap.com> Mon, 03 July 2006 15:23 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQH1-0000tq-Qo; Mon, 03 Jul 2006 11:23:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQH0-0000ti-HT for tls@ietf.org; Mon, 03 Jul 2006 11:23:42 -0400
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQGz-0005L8-4t for tls@ietf.org; Mon, 03 Jul 2006 11:23:42 -0400
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA25871 for <tls@ietf.org>; Mon, 3 Jul 2006 17:23:39 +0200 (MESZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200607031523.RAA09074@uw1048.wdf.sap.corp>
Orig-To: tls@ietf.org
To: tls@ietf.org
Date: Tue, 27 Jun 2006 22:39:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc:
Subject: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
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
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] 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