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

Dave Cridland <dave@cridland.net> Thu, 18 March 2010 13:45 UTC

Return-Path: <dave@cridland.net>
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 5050D3A683A; Thu, 18 Mar 2010 06:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level:
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, 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 eXuIaI1W7LDb; Thu, 18 Mar 2010 06:45:06 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id EA1223A6907; Thu, 18 Mar 2010 06:45:05 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id CE7B611680C6; Thu, 18 Mar 2010 13:45:13 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QNUDB1y1PBh; Thu, 18 Mar 2010 13:45:13 +0000 (GMT)
Received: from puncture (unknown [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 709FB11680C3; Thu, 18 Mar 2010 13:45:13 +0000 (GMT)
References: <20100317231522.GA18167@Sun.COM> <808FD6E27AD4884E94820BC333B2DB775848524D7A@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775848524D7A@NOK-EUMSG-01.mgdnok.nokia.com>
MIME-Version: 1.0
Message-Id: <2462.1268919913.457533@puncture>
Date: Thu, 18 Mar 2010 13:45:13 +0000
From: Dave Cridland <dave@cridland.net>
To: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>, Nicolas Williams <Nicolas.Williams@sun.com>, "channel-binding@ietf.org" <channel-binding@ietf.org>, SASL Working Group <sasl@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 18 Mar 2010 07:16:48 -0700
Subject: Re: [TLS] [sasl] 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: Thu, 18 Mar 2010 13:45:08 -0000

On Thu Mar 18 11:49:11 2010, Pasi.Eronen@nokia.com wrote:
> 
> A question for SASL: both GS2 and SCRAM are currently in
> RFC Editor AUTH48, and they have a normative reference
> to the IANA registration page for 'tls-unique'.
> 
> Since it appears we're about to change that registration
> quite radically, what's the impact on GS2/SCRAM? Have GS2
> and/or SCRAM implementors implemented the 'tls-unique'
> binding?
> 
> 
This SCRAM implementor did, yes. And I followed the specification.  
Aren't I naïve?


> And should we publish the RFCs at this time, if we know one
> of the normative references is, well, unstable (likely to
> change in non-backward-compatible way soon)?
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On  
> Behalf Of
> > ext Nicolas Williams
> > Sent: 18 March, 2010 01:15
> > To: channel-binding@ietf.org; sasl@ietf.org; tls@ietf.org
> > Subject: [sasl] Updates to draft-altman-tls-channel-bindings  
> (PLEASE
> > REVIEW)
> >
> > Now that TLS re-negotiation security (RFC5746) is done we need to
> > finish
> > draft-altman-tls-channel-bindings.
> >
> > It's become clear that MSFT implemented and deployed something  
> slightly
> > different than the 'tls-unique' binding description that had been
> > registered.  They seem to be the only implementors to date; their
> > implementation is secure, therefore I propose that we simply  
> modify the
> > description of 'tls-unique' and be done.
> >
> > The differences are:
> >
> >  - it's not always the client's Finished message, but the _first_
> >    Finished message in the relevant handshake (in a session  
> resumption
> >    handshake the server sends its Finished message first);
> >

This is quite annoying. It's harder for me (personally) to implement,  
given the APIs I'm working with. Moreover, since it changes with a  
(relatively) unusual feature of TLS, I suspect people will get this  
wrong - most uses of TLS in, for example, XMPP or IMAP do not appear  
to use session resumption much.


> >  - the Finished message is taken from the latest/inner-most TLS
> >    handshake, rather than the outer-most one
> >

This unnerves me. I'd prefer to use only the first negotiation from  
each side, since that effectively means that both ends know which one  
that was. Moreover, in principle a negotiation could occur during the  
SASL exchange, which would then invalidate the channel binding.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade