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
- [TLS] Updates to draft-altman-tls-channel-binding… Nicolas Williams
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Pasi.Eronen
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Dave Cridland
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Simon Josefsson
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [sasl] [CHANNEL-BINDING] Updates to dra… Larry Zhu
- Re: [TLS] [sasl] [CHANNEL-BINDING] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [sasl] [CHANNEL-BINDING] Updates to dra… Alexey Melnikov
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Alexey Melnikov
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Simon Josefsson
- Re: [TLS] [CHANNEL-BINDING] Updates to draft-altm… Simon Josefsson
- Re: [TLS] [CHANNEL-BINDING] Updates to draft-altm… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] Updates to Martin Rex
- [TLS] Updates to draft-altman-tls-channel-binding… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] Updates to draft-altm… Alexey Melnikov
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Nicolas Williams
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Nicolas Williams
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Larry Zhu
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Larry Zhu
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Simon Josefsson
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Simon Josefsson
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Larry Zhu
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to Martin Rex
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to Simon Josefsson
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to dra… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to Martin Rex
- Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to Larry Zhu
- [TLS] Avoiding CB sync problem via server-side so… Nicolas Williams
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Eliot Lear
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Nicolas Williams
- Re: [TLS] [sasl] Updates to draft-altman-tls-chan… Sean Turner