Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

Simon Josefsson <simon@josefsson.org> Wed, 04 November 2009 19:26 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 254DD3A68E7; Wed, 4 Nov 2009 11:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.695
X-Spam-Level:
X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599]
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 cUoplztkeEdB; Wed, 4 Nov 2009 11:26:13 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D05A73A67B6; Wed, 4 Nov 2009 11:26:12 -0800 (PST)
Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nA4JQUKj022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 20:26:32 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BAE0E5@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> <20091104181257.GY1105@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:091104:tls@ietf.org::E+MsoNkDbZ0j/YBl:0Uvi
X-Hashcash: 1:22:091104:nicolas.williams@sun.com::n3HUsOfNYddl4ZyB:1bDE
X-Hashcash: 1:22:091104:channel-binding@ietf.org::RXChJT0iKFtgtKX5:2Ceb
X-Hashcash: 1:22:091104:sasl@ietf.org::4t7yvQqTduGLQQSN:LgVb
Date: Wed, 04 Nov 2009 20:26:30 +0100
In-Reply-To: <20091104181257.GY1105@Sun.COM> (Nicolas Williams's message of "Wed, 4 Nov 2009 12:12:58 -0600")
Message-ID: <87aaz2jdll.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.2 at yxa-v
X-Virus-Status: Clean
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
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: Wed, 04 Nov 2009 19:26:14 -0000

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

> On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote:
>> <Pasi.Eronen@nokia.com>; writes:
>> 
>> > Can you check if the latest text proposals (Nico's email on 
>> > October 30th, starting "I spoke at length with Larry", and 
>> > my email earlier today) make the situation clearer?
>> 
>> I have the same question as Martin Rex: what is the actual semantic that
>> is wanted?  I thought I understood what was intended, but given this
>> discussion my understanding of what was intended may have been wrong.
>
> The desired semantic is that tls-unique channel bindings are a channel
> binding in the RFC5056 sense, for a "TLS channel", with this particular
> feature (from the I-D):
>
>    o  Channel binding type: unique
>
> (which RFC5056 defines).
>
> Was this not utterly clear already?  How could it not have been?
>
> The only possible point of contention from the above description is just
> what a "TLS channel" might be.  And the only reasons for that are:
>
>  - RFC5246 and predecessors don't define a name for what we've been
>    calling a "TLS connection";
>
>  - Session resumption might cause someone to be confused and think that
>    tls-unique refers to the client's Finished message from the resumed
>    session;
>
>  - Re-negotiation might cause someone to be confused and think that
>    tls-unique refers to the client's Finished message from the
>    re-negotiated "TLS connection".
>
> Let's dispose of these for once and for all:
>
>  - We shall use "TLS connection" to refer to the TLS state created by an
>    exchange beginning with a Client Hello message, followed by a TLS
>    handshake sequence (which involves a ServerHello, a variety of
>    optional messages such as Certificate, and ends in an optional
>    ChangeCipherSpec message exchange) followed by an exchange of
>    Finished messages.
>
>  - Session resumption establishes new state as per the previous
>    definition of "TLS connection", therefore it establishes a new "TLS
>    connection", even though session resumption does NOT establish a new
>    session.  Therefore, the tls-unique channel binding for a "TLS
>    connection" that resumes a session, MUST be the client's Finished
>    message from the new connection, not the old session.
>
>  - Re-negotiation consists of initiating a new "TLS connection" while
>    using another "TLS connection" record layer for integrity (and
>    usually also confidentiality) protection of the re-negotiation.
>
>    As such re-negotiation creates a new "TLS connection".  In this case
>    want the tls-unique channel binding to be used by the application to
>    be that of the first "TLS connection", that is, the one whose
>    ClientHello and handshake were not protected by any other "TLS
>    connection".
>
>    (It follows that even if the client does N re-negotiations, where N >
>    2, we still want the application to use the tls-unique channel
>    binding of the first "TLS connection", the one whose handshake was
>    not protected by any other "TLS connection".)
>
> Therefore a "TLS channel" is really: a "TLS connection", as defined
> above, whose handshake was not protected by any other "TLS connection".
>
> This is a significantly more rigorous description than the ones we've
> discussed so far.  Do you agree that it's air-tight?  Should I propose
> new text that adds the above definitions of "TLS connection" and "TLS
> channel"?  I think I should, so I will, shortly.

With that definition, one couldn't use tls-unique channel binding to
bind to the authentication credentials associated with a TLS channel
uniquely -- a TLS re-negotiation doesn't change the channel binding
data, but it may change the authentication credentials.

I believe that problem needs to be explained in the security
consideration -- it would be easy to think that channel binding data can
be used to get a cryptographic association with the user credentials
used for that channel.

Otherwise I don't see any problem with this definition.

/Simon