[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
- [TLS] What's the right version number in the PreM… Xuelei Fan
- Re: [TLS] What's the right version number in the … Michael D'Errico
- Re: [TLS] What's the right version number in the … Martin Rex
- Re: [TLS] What's the right version number in the … Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] What's the right version number in the … Kyle Hamilton
- Re: [TLS] What's the right version number in the … Michael D'Errico
- Re: [TLS] What's the right version number in the … Xuelei Fan
- Re: [TLS] What's the right version number in the … Martin Rex
- Re: [TLS] What's the right version number in the … Andrei Popov
- Re: [TLS] What's the right version number in the … Michael D'Errico
- [TLS] [Fwd: Re: What's the right version number i… Michael D'Errico