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

Martin Rex <mrex@sap.com> Wed, 11 August 2010 08:38 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 643C03A6A47 for <tls@core3.amsl.com>; Wed, 11 Aug 2010 01:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.79
X-Spam-Level:
X-Spam-Status: No, score=-9.79 tagged_above=-999 required=5 tests=[AWL=0.459, 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 vYV25rMQjqfk for <tls@core3.amsl.com>; Wed, 11 Aug 2010 01:38:21 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 163E33A6A3F for <tls@ietf.org>; Wed, 11 Aug 2010 01:38:20 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o7B8cor2010988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 10:38:55 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201008110838.o7B8cnV5020569@fs4113.wdf.sap.corp>
To: Xuelei.Fan@Sun.COM
Date: Wed, 11 Aug 2010 10:38:49 +0200
In-Reply-To: <4C620015.5070305@Sun.COM> from "Xuelei Fan" at Aug 11, 10 09:42:45 am
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: 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: Wed, 11 Aug 2010 08:38:22 -0000

Xuelei Fan wrote:
> 
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> > Martin Rex <mrex@sap.com> wrote:
> > >
> > > 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.

Technically, this should be just fine.

> 
> > 
> > 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.

You are probably right, sending the protocol version from the
session that is proposed for resume is the more conservative approach,
with a lesser likelihood to tickle bugs.


IF the server agrees to session resumption, then the session MUST be
resumed with the original protocol version.  It would be bug in the
server if it would resume the session with a different protocol
version, and it would be a bug in the client to agree to resuming
the session with a different protocol version.

AFAIK, the architecture behind TLS session caching is that it is
resumed "as is" from the session cache, with all characteristics as
established in the full handshake that created this session
that includes protocol version, cipher suite, compression alg,
active TLS extensions.

Doing otherwise might have unexpected side effects.  A TLS session
resumption omits the exchange of certificate messages and therefore
might omit some checks that were (for whatever reason) tied into
the certificate path validation.


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

Anyone know which TLS client would agree to resuming with a different
protocol version if a buggy server would do this based on the
ClientHello.client_version differing from the protocol version of
the cached session that is proposed for resumption?

-Martin