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