[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 (MET DST)
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