Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:

Martin Rex <Martin.Rex@sap.com> Mon, 02 November 2009 16:34 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 EA0C73A67A5; Mon, 2 Nov 2009 08:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.906
X-Spam-Level:
X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 nIH4OQYLQ2zg; Mon, 2 Nov 2009 08:34:53 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E8E4928C0ED; Mon, 2 Nov 2009 08:34:52 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA2GZBsu001915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:35:11 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp>
To: simon@josefsson.org
Date: Mon, 02 Nov 2009 17:35:10 +0100
In-Reply-To: <87hbtcc457.fsf@mocca.josefsson.org> from "Simon Josefsson" at Nov 2, 9 04:55:48 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: mrex@sap.com, channel-binding@ietf.org, sasl@ietf.org, Nicolas.Williams@sun.com, tls@ietf.org
Subject: Re: [TLS] RESOLVED (Re: [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: Mon, 02 Nov 2009 16:34:54 -0000

Simon Josefsson wrote:
> 
> Martin Rex <Martin.Rex@sap.com> writes:
> 
> > It might be easier to _NOT_ key on the finished message, but on the
> > master secret instead.
> 
> That was my conclusion as well, hence
> http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00
> which uses the TLS PRF interface.
> 
> For -02 I also added hashing the Finished message, to match the
> semantics for connection/session (regardless of its definition) of
> draft-altman-tls-channel-bindings, but I'd prefer to avoid it
> completely.

If you refer to the TLS-extractor interface with TLS PRF, that does
unconditionally include the client.random and server.random in the
computation and therefore the output will differ for different
incarnations (resumes) of the same TLS session.  That is 
comparable to keying to the _most_recent_ finished message -- with
__NO__ special cased for TLS session resume and TLS renogiation.

-Martin