Re: [TLS] What's the right version number in the PreMasterSecret

Xuelei Fan <Xuelei.Fan@Sun.COM> Wed, 11 August 2010 01:42 UTC

Return-Path: <Xuelei.Fan@Sun.COM>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47EAA3A68C6 for <tls@core3.amsl.com>; Tue, 10 Aug 2010 18:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVbp0No7-vsH for <tls@core3.amsl.com>; Tue, 10 Aug 2010 18:42:53 -0700 (PDT)
Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 053B93A68B6 for <tls@ietf.org>; Tue, 10 Aug 2010 18:42:52 -0700 (PDT)
Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7B1hR28013326 for <tls@ietf.org>; Wed, 11 Aug 2010 01:43:27 GMT
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L6Y00100SO6RS00@fe-emea-09.sun.com> for tls@ietf.org; Wed, 11 Aug 2010 02:42:55 +0100 (BST)
Received: from [129.150.0.9] ([unknown] [129.150.0.9]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6Y002X3SRGG180@fe-emea-09.sun.com>; Wed, 11 Aug 2010 02:42:55 +0100 (BST)
Date: Wed, 11 Aug 2010 09:42:45 +0800
From: Xuelei Fan <Xuelei.Fan@Sun.COM>
In-reply-to: <op.vg8aifvdqrq7tp@acorna.invalid.invalid>
Sender: Xuelei.Fan@Sun.COM
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Message-id: <4C620015.5070305@Sun.COM>
X-Enigmail-Version: 1.1.1
References: <201008101457.o7AEv9e7019723@fs4113.wdf.sap.corp> <op.vg8aifvdqrq7tp@acorna.invalid.invalid>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
Cc: tls@ietf.org
Subject: Re: [TLS] What's the right version number in the PreMasterSecret
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Aug 2010 01:42:54 -0000

On 8/10/2010 11:26 PM, Yngve N. Pettersen (Developer Opera Software ASA)
wrote:
> On Tue, 10 Aug 2010 16:57:09 +0200, Martin Rex <mrex@sap.com> wrote:
> 
>> Michael D'Errico wrote:
>>>
>>> Based on the scenarios below, it looks like Opera is doing the right
>>> thing during the renegotiation while IE 8 is not.
>>
>> Opera is sending the correct client_version in the RSA PreMaster Secret
>> in both handshakes (initial and renegotiation).  Handshakes in the
>> originial SSLv3 and TLS protocol were completely independent and
>> self-contained, so the back-reference of the client_version in
>> RSA premaster secret is ALWAYS to the ClientHello handshake message
>> of the current handshake.
>>
>> But both browsers should actually be sending their highest supported
>> protocol version as client_version on EVERY ClientHello handshake
>> message--independent of whether they propose session resumption--
>> and both browsers appear to flunk on this point.
> 
> I have not been able to locate the exact reason for our policy, but if
> we have an active session against a server we will use the negotiated
> protocol version in future handshakes.
Java (SunJSSE) use the same policy as Opera, use the negotiated protocol
version for renegotiation.

> 
> This policy is 11+ years old, and was probably implemented because there
> was some kind of problem with resuming sessions using a Hello protocol
> version different from the one we used when setting up the session.
> 
> It may be possible to remove this, along with all the version fallback
> code, when we enter strict Renego patch mode.
I'm a little worried about the interoperability. I'm not sure, but if
some vendors care about the protocol version in renegotiation
ClientHello, for example, comparing the ClientHello.client_version with
the cached negotiated protocol version.

Anyone know which TLS implementations do not use the negotiated protocol
version for abbreviated handshake?

Thanks,
Xuelei (Andrew) Fan