Re: [TLS] [sasl] lasgt call comments (st Call:
Martin Rex <Martin.Rex@sap.com> Wed, 28 October 2009 20:49 UTC
Return-Path: <Martin.Rex@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 910E73A6A6A; Wed, 28 Oct 2009 13:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.424
X-Spam-Level:
X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qHyGQPzgBfkw; Wed, 28 Oct 2009 13:49:17 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DF1143A686C; Wed, 28 Oct 2009 13:49:15 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n9SKnSDG021053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 21:49:28 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com
Date: Wed, 28 Oct 2009 21:49:28 +0100
In-Reply-To: <20091028163322.GO1105@Sun.COM> from "Nicolas Williams" at Oct 28, 9 11:33:23 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: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org
Subject: Re: [TLS] [sasl] lasgt call comments (st Call:
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, 28 Oct 2009 20:49:18 -0000
Nicolas Williams wrote: > > Here, then, is my proposed clarification: > > Description: The client's TLS Finished message (note: the Finished > struct) from the first handshake of the TLS session. > > (Yes, I changed "connection" to "session", followed by this:) > > Clarification: If a connection resumes a previous session, then the > Finished message to use is that of the new session, not the one from > the original session. If a session has multiple handshakes and, > therefore, multiple client Finished messages, the first client > Finished message of that session is the one to use as the tls-unique > channel binding. This description/terminology about resume/previous/new/original session is confusing and wrong. If a TLS session is resumed, then the result is always the SAME session, which is indicated by the use of the SAME session id (and internally, by the use of the same underlying master secret). A cached TLS session can be resumed quite often and simultaneously is parallel (which leads to multiple parallel/forked sessions). The session keys are newly re-derived for each connection and each session resume, and they should be unique because of the client random and server random that go into the session key derivation of every new connection (=resumed session). A resumed TLS session will also NOT exchange (and therefore not verify) any certificates. A new TLS session is created when one of - the client does not propose TLS session resume at all - the server does not agree to TLS session resumption, and creates and returns a new/different session id and performs a full handshake - the client performs a renegotiate for an established session (usually upon request from the server) and the server goes through a full ssl handshake. Since the finished messages of the tls handshake cover the client random and server random of the SSL handshake, the finished messages are going to be unique for each connection, even for two resumes of the same session. > From an application programming interface (API) > perspective, the client's Finished message is saved in the contextual > object handle that the client and server applications obtain when > they initiate or resume a TLS session; later, when the applications > request the tls-unique channel binding, the TLS implementation > retrieves the saved first client Finished message from that context > handle. Asking the TLS protocol stack to memorize the original finished message sounds awkward to me. The thing that the ssl session cache is already memorizing for a session is the master secret, so maybe deriving something from that would be better suited for the purpose than a requirement to store the original finished message. -Martin
- [TLS] Last Call: draft-altman-tls-channel-binding… The IESG
- Re: [TLS] lasgt call comments (st Call: draft-alt… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: Martin Rex
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- [TLS] RESOLVED (Re: [sasl] lasgt call comments (s… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Simon Josefsson
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Peter Gutmann
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLV… Martin Rex
- Re: [TLS] [CHANNEL-BINDING] Unrelated (Re: RESOLV… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Pasi.Eronen
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Michael D'Errico
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Jeffrey Hutzelman
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Sam Hartman
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] lasgt call comments (st Call: draft-alt… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Larry Zhu
- [TLS] New Problem (Was: Last Call: draft-altman-t… Nicolas Williams
- Re: [TLS] New Problem (Was: Last Call: draft-altm… Larry Zhu
- Re: [TLS] [CHANNEL-BINDING] New Problem (Was: Las… Nicolas Williams