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