Re: [TLS] [CHANNEL-BINDING] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)

Simon Josefsson <simon@josefsson.org> Fri, 19 March 2010 08:57 UTC

Return-Path: <simon@josefsson.org>
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 7FED43A686B; Fri, 19 Mar 2010 01:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.164
X-Spam-Level:
X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13]
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 x4LYI6CaPlcm; Fri, 19 Mar 2010 01:57:32 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id C96673A691A; Fri, 19 Mar 2010 01:57:26 -0700 (PDT)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2J8vYg7020316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Mar 2010 09:57:35 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20100317231522.GA18167@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100319:tls@ietf.org::rnm0pADBYXRcl0MC:fDc
X-Hashcash: 1:22:100319:nicolas.williams@sun.com::xl39c/pTcXNZy+4D:AvUV
X-Hashcash: 1:22:100319:channel-binding@ietf.org::BrFR3u3UeBqL39Qu:At1n
X-Hashcash: 1:22:100319:sasl@ietf.org::wvZnU1mTmTS7VqEh:il5K
Date: Fri, 19 Mar 2010 09:57:34 +0100
In-Reply-To: <20100317231522.GA18167@Sun.COM> (Nicolas Williams's message of "Wed, 17 Mar 2010 18:15:22 -0500")
Message-ID: <87zl243czl.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] [CHANNEL-BINDING] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Fri, 19 Mar 2010 08:57:34 -0000

Nicolas Williams <Nicolas.Williams@sun.com> writes:

> +   Description: The first TLS Finished message sent (note: the Finished
> +   struct) in the most recent TLS handshake of the TLS connection being
> +   bound to (note: TLS connection, not session, so that the channel
> +   binding is specific to each connection regardless of whether session
> +   resumption is used).  If TLS re-negotiation takes place before the
> +   channel binding operation, then the first TLS Finished message sent
> +   of the latest/inner-most TLS connection is used.  Note that for full
> +   TLS handshakes the first Finished message is sent by the client,
> +   while for abbreviated TLS handshakes the first Finished message is
> +   sent by the server.

I don't follow this fully -- IF you use the latest TLS finished message,
the channel binding data WILL be specific the each TLS session, and it
will depend on whether the session is resumed or not, which is contrary
to this assertion:

> +   bound to (note: TLS connection, not session, so that the channel
> +   binding is specific to each connection regardless of whether session
> +   resumption is used).  If TLS re-negotiation takes place before the

I wonder what happens if a TLS re-negotiation happens after the client
started its authentication attempt (for GS2-KRB5: sent the AP-REQ) but
before the server has responded (for GS2-KRB5: sent the AP-REP)?  Then
authentication will fail, it seems, because the client and server will
have different ideas of what the channel binding data should be.

/Simon