Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt

David Hopwood <david.nospam.hopwood@blueyonder.co.uk> Mon, 03 July 2006 17:16 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS2U-00027C-6r; Mon, 03 Jul 2006 13:16:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS2S-000276-Ho for tls@ietf.org; Mon, 03 Jul 2006 13:16:48 -0400
Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxS2R-0003wx-5Z for tls@ietf.org; Mon, 03 Jul 2006 13:16:48 -0400
Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1FxS2Q-0000t8-Dv for tls@ietf.org; Mon, 03 Jul 2006 18:16:46 +0100
Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1FxS2P-0007wF-UA for tls@ietf.org; Mon, 03 Jul 2006 18:16:46 +0100
Message-ID: <44A950EE.90504@blueyonder.co.uk>
Date: Mon, 03 Jul 2006 18:16:30 +0100
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tls@ietf.org
Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
References: <B356D8F434D20B40A8CEDAEC305A1F2402D9BF00@esebe105.NOE.Nokia.com>
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402D9BF00@esebe105.NOE.Nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: david.nospam.hopwood@blueyonder.co.uk
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:
> 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.

Rather, that clients MUST send ClientHello records with the two
version numbers equal.

Saying just that they "MUST be equal" would allow servers to reject
records where they are not equal, which would be incorrect.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls