[TLS] What's the right version number in the PreMasterSecret for renegotiation

Xuelei Fan <Xuelei.Fan@Sun.COM> Tue, 10 August 2010 02:29 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 AD09B3A69F2 for <tls@core3.amsl.com>; Mon, 9 Aug 2010 19:29:32 -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 gIpVc+n1nK+7 for <tls@core3.amsl.com>; Mon, 9 Aug 2010 19:29:31 -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 58E8B3A69F1 for <tls@ietf.org>; Mon, 9 Aug 2010 19:29:31 -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 o7A2U5Qb005874 for <tls@ietf.org>; Tue, 10 Aug 2010 02:30:05 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 <0L6W00200ZYJJO00@fe-emea-09.sun.com> for tls@ietf.org; Tue, 10 Aug 2010 03:29:41 +0100 (BST)
Received: from [129.150.24.4] ([unknown] [129.150.24.4]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6X00HPJ09E4T30@fe-emea-09.sun.com> for tls@ietf.org; Tue, 10 Aug 2010 03:29:41 +0100 (BST)
Date: Tue, 10 Aug 2010 10:29:31 +0800
From: Xuelei Fan <Xuelei.Fan@Sun.COM>
Sender: Xuelei.Fan@Sun.COM
To: tls@ietf.org
Message-id: <4C60B98B.6000004@Sun.COM>
X-Enigmail-Version: 1.1.1
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
Subject: [TLS] What's the right version number in the PreMasterSecret for renegotiation
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: Tue, 10 Aug 2010 02:29:32 -0000

In RFC4346/5246, the specification for client_version in the
PreMasterSecret is described as:
---------------
      struct {
          ProtocolVersion client_version;
          opaque random[46];
      } PreMasterSecret;

      client_version The latest (newest) version supported by the
         client.  This is used to detect version roll-back attacks.
         Upon receiving the premaster secret, the server SHOULD check
         that this value matches the value transmitted by the client in
         the client hello message.

      ....

   Note: The version number in the PreMasterSecret MUST be the version
         offered by the client in the ClientHello, not the version
         negotiated for the connection.  This feature is designed to
         prevent rollback attacks.
---------------

The spec is clear for initial handshaking. But while testing
renegotiation, we get two different interpretations of the version
number in the PreMasterSecret. We noticed Opera (10.50) uses the version
number offered by the renegotiation ClientHello, while Microsoft IE 8
(IE 8 at Windows 7) uses the version number offered by the ClientHello
in the initial handshaking.

For Opera, the scenario looks like:

    Opera <--------------> TLS server
         --->ClientHello V1.2--->
         <---ServerHello V1.1<---
         ...
         --->PreMasterSecret (v1.2)--->  (as expected)
         ...
         <---HelloRequest<----
         ---->ClientHello v1.1----> (ask for an abbreviated handshake)
         <---ServerHello V1.1<---   (not resumable, new session)
         ...
         --->PreMasterSecret (v1.1)---> (*)


For IE 8, the scenario looks like:

    IE 8<--------------> TLS server
         --->ClientHello V1.2--->
         <---ServerHello V1.1<---
         ...
         --->PreMasterSecret (v1.2)--->  (as expected)
         ...
         <---HelloRequest<----
         ---->ClientHello v1.1----> (ask for an abbreviated handshake)
         <---ServerHello V1.1<---   (not resumable, new session)
         ...
         --->PreMasterSecret (v1.2)---> (**)

(*) Opera uses the version number offered by the ClientHello in the
renegotiation handshaking.
(**) IE 8 uses the version number offered by the ClientHello in the
initial handshaking.

Please help to clarify what's the correct version number choice for
renegotiation.

Thanks,
Xuelei (Andrew) Fan