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

Martin Rex <mrex@sap.com> Tue, 10 August 2010 14:56 UTC

Return-Path: <mrex@sap.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 7D2023A6860 for <tls@core3.amsl.com>; Tue, 10 Aug 2010 07:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.779
X-Spam-Level:
X-Spam-Status: No, score=-9.779 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 Y3ABwOPsJyfV for <tls@core3.amsl.com>; Tue, 10 Aug 2010 07:56:42 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 45BF93A687A for <tls@ietf.org>; Tue, 10 Aug 2010 07:56:42 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o7AEvAp7028504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2010 16:57:15 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201008101457.o7AEv9e7019723@fs4113.wdf.sap.corp>
To: mike-list@pobox.com
Date: Tue, 10 Aug 2010 16:57:09 +0200
In-Reply-To: <4C60C562.6090908@pobox.com> from "Michael D'Errico" at Aug 9, 10 08:20:02 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: Xuelei.Fan@Sun.COM, 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
Reply-To: mrex@sap.com
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 14:56:43 -0000

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.


-Martin

> 
> Xuelei Fan wrote:
> > 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>