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

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 04 November 2009 18:06 UTC

Return-Path: <Nicolas.Williams@sun.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 02E3F3A691D; Wed, 4 Nov 2009 10:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 nQIP4XF4ft5L; Wed, 4 Nov 2009 10:06:50 -0800 (PST)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id E2BDD3A6922; Wed, 4 Nov 2009 10:06:49 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4I77us018389; Wed, 4 Nov 2009 18:07:07 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA4I77uk050114; Wed, 4 Nov 2009 11:07:07 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4HtcTm008250; Wed, 4 Nov 2009 11:55:38 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4HtbZ0008249; Wed, 4 Nov 2009 11:55:37 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 04 Nov 2009 11:55:37 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Pasi.Eronen@nokia.com
Message-ID: <20091104175537.GX1105@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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com>
User-Agent: Mutt/1.5.7i
Cc: simon@josefsson.org, channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org
Subject: Re: [TLS] [sasl] 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 18:06:51 -0000

On Wed, Nov 04, 2009 at 03:34:38PM +0100, Pasi.Eronen@nokia.com wrote:
> Simon Josefsson wrote:
> > This reminded me of an earlier observation, and it might be relevant
> > to re-iterate it here.  Consider this:
> > 
> > Day 1:
> > 
> > 1. Client establish TLS anon-anon to server.
> > 2. User authenticates using SCRAM with channel binding to the TLS
> >    channel
> > 3. User/client disconnects
> > 
> > Day 2:
> > 
> > 4. Client resumes the TLS anon-anon connection
> > 5. Client rehandshake with X.509 client + server authentication
> > 6. User authenticates using SCRAM with channel binding to the
> >    TLS channel
> > 7. User/client disconnects
> > 
> > Day 3:
> > 
> > 7. Client resumes the TLS session
> > 8. Client rehandshake it as anon-anon
> > 9. User authenticates using SCRAM with channel binding to the
> >    TLS channel
> > 10. User/client disconnects
> > 
> > With draft-altman-tls-channel-bindings-07, the channel binding data
> > used in all three SCRAM authentications is the same bit sequence.
> 
> That certainly was not the intent (the Finished messages used by
> SCRAM would be from steps 1, 4, and 7 -- and they're all different).

Indeed, that's absolutely not the intent.  The intent is that you use
the first client Finished message sent on each of those "connections".

Note, incidentally, that Simon's view of how tls-unique was intended to
work, would not be flawed, cryptographically.  It wouldn't interoperate
with other implementations, and it'd be hard to implement (since it
means updating saved session state).  It would conflict the very name of
the channel binding type and it's description as being a "unique"
channel binding type in the RFC5056 sense -- that should be the biggest
clue that Simon's interpretation is incorrect.

I have a very, very hard time understanding how this might not by now be
clear.  It doesn't help that TLS doesn't have a name for the entity from
which we're extracting the channel binding, but that's the only real
problem here.

I also have a very, very hard time understanding how the previous text
could have led anyone to think that TCP connection state should track
TLS channel binding data.  RFC5246 may not have a name for the entity...
but it does speak of "TLS connections", which you can see from the
naming of section 6.1: "Connection States".

Nonetheless I'm happy to revise text to make this matter clearer.  I'd
be happy even to introduce text naming that entity which RFC5246 does
not name.

Nico
--