Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Martin Rex <martin.rex@sap.com> Mon, 03 July 2006 17:09 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRva-0000oz-Ul; Mon, 03 Jul 2006 13:09:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRvZ-0000ou-MO for tls@ietf.org; Mon, 03 Jul 2006 13:09:41 -0400
Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRvZ-0003m1-8z for tls@ietf.org; Mon, 03 Jul 2006 13:09:41 -0400
Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA08910; Mon, 3 Jul 2006 19:09:37 +0200 (MESZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200607031708.TAA13289@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
To: Pasi.Eronen@nokia.com
Date: Mon, 03 Jul 2006 19:08:59 +0200
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402D9BF00@esebe105.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Jul 3, 6 07:14:15 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: tls@ietf.org
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
Pasi.Eronen@nokia.com wrote: > > 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? It SHOULD contain the lowest protocol version that the client is willing to negotiate. Anything else is going to cause interoperability problems. The most interesing question: what does the installed base do today when it receives a client hello with a 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS record protocol AND in the client_version of the ClientHello message. I expect some servers to choke heavily (and rightfully). The potential ambiguity is only for the casual reader, there definitely never was an abiguity for the careful protocol implementor. The SSLv3 spec (which somewhat happened after the fact) does not contain any ambiguity either, because it doesn't define anything other than {3, 0} PDUs and version numbers. The root of any ambiguity is that the spec fails to clearly seperare version tags for the purpose of negotation (client_version, server_version) and version tags (version) that indicates a particular PDU encoding. The description of the PDUs in the appendix of SSL/TLS specs contains the protocol version in exactly three distinct variants: version client_version (only in ClientHello and PreMasterSecret) server_version (only in ServerHello) All existing specs were NOT ambiguous in that exactly one field was supposed to contain the negotiated version number. And from the description of the individual PDUs in Appendix A, it should have been obvious to implementors which version field should have been meant, and which one should not have been meant. There are very few error-free specs, and this particular error (and the correct wording) are fairly easy to figure, IMHO. > > 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. fine. > - When configured in "TLS10 only" mode, sends {03,01} in both fields fine. > - Mozilla Firefox 1.5 > - Seems to send V2 ClientHello no matter what the settings?? fine. > - MS Internet Explorer 6.0 > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields broken. > - SunJSSE (JDK 1.4.2) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields broken. > - GnuTLS (10.0.20) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields broken. > - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, > sends V3 ClientHello with {03,02} in both fields broken. > > In other words: All these implementation seem to follow the > rule that TLSPlaintext.version==ClientHello.client_version, or > use V2 ClientHellos... Didn't you just say that OpenSSL and Mozilla used a correct behaviour on the client side? The more interesting question is what SSL/TLS servers do upon receipt, and in particular what they do upon receipt of a high up version number, like {03,03} or {03,04}. > > 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. The clarification should say that there's an awfully large installed base that is broken and that the server will likely have to entirely ignore the version number in the record protocol when processing a ClientHello message, and upons sending, should send the lowest version number that they're willing to use. This makes protocol layering not as independent as it should be. -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