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 (Nicolas Williams)
Date: Wed, 28 Oct 2009 21:49:28 +0100 (MET)
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