Re: [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)
Simon Josefsson <simon@josefsson.org> Thu, 18 March 2010 15:22 UTC
Return-Path: <simon@josefsson.org>
X-Original-To: channel-binding@core3.amsl.com
Delivered-To: channel-binding@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473803A6C36; Thu, 18 Mar 2010 08:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level:
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.503, 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 Fa+Ld9sOXDkK; Thu, 18 Mar 2010 08:22:28 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2442F3A6C09; Thu, 18 Mar 2010 08:22:24 -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 o2IFMKXu030325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Mar 2010 16:22:23 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Dave Cridland <dave@cridland.net>
References: <20100317231522.GA18167@Sun.COM> <808FD6E27AD4884E94820BC333B2DB775848524D7A@NOK-EUMSG-01.mgdnok.nokia.com> <2462.1268919913.457533@puncture>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100318:tls@ietf.org::T+aO0Gd+NZYyT0in:2TMS
X-Hashcash: 1:22:100318:dave@cridland.net::0aSxh55pkJ7RUXR3:30d+
X-Hashcash: 1:22:100318:sasl@ietf.org::mB/uh/hAwk3LJj29:7p65
X-Hashcash: 1:22:100318:pasi.eronen@nokia.com::4J7JnjIi4lzw210Z:5KBl
X-Hashcash: 1:22:100318:channel-binding@ietf.org::XHFqmiU7ktHBUu2i:4Hnj
X-Hashcash: 1:22:100318:nicolas.williams@sun.com::bd8kCHb3qbZWl4HX:IqxL
Date: Thu, 18 Mar 2010 16:22:20 +0100
In-Reply-To: <2462.1268919913.457533@puncture> (Dave Cridland's message of "Thu, 18 Mar 2010 13:45:13 +0000")
Message-ID: <877hp98xjn.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="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
Cc: "channel-binding@ietf.org" <channel-binding@ietf.org>, "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>, SASL Working Group <sasl@ietf.org>, Nicolas Williams <Nicolas.Williams@sun.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)
X-BeenThere: channel-binding@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of channel binding IANA registry requests and specifications <channel-binding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2010 15:22:42 -0000
Dave Cridland <dave@cridland.net> writes: > 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? I've done testing with the IANA registered tls-unique too. GnuTLS added APIs for this two major/stable release cycles ago (2008-10) which is now widely deployed. It may be that the APIs are flexible enough to be able to implement the new semantics, although I suppose applications would need to be modified. I haven't analyzed the details yet... What kind of software has Microsoft deployed already that use tls-unique? I thought GS2 and SCRAM were the most ready protocols that used it, and they are still not final. Changing the IANA specification for tls-unique long after it has been registered and published seems bad to me. Bad enough to make me think that it is a mistake for GS2/SCRAM to reference the IANA specification normatively -- if the IANA registry is not immutable, interop is not possible. There is always the option of making GS2/SCRAM reference 'tls-unique2' and specify that clearly and stable once and for all. Then we can let 'tls-unique' be the interop mess that it appears to be right now. /Simon > >> 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 > _______________________________________________ > CHANNEL-BINDING mailing list > CHANNEL-BINDING@ietf.org > https://www.ietf.org/mailman/listinfo/channel-binding
- [CHANNEL-BINDING] Updates to draft-altman-tls-cha… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Pasi.Eronen
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Dave Cridland
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Simon Josefsson
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Larry Zhu
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Alexey Melnikov
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Alexey Melnikov
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Simon Josefsson
- Re: [CHANNEL-BINDING] Updates to draft-altman-tls… Simon Josefsson
- Re: [CHANNEL-BINDING] Updates to draft-altman-tls… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] Updates to Martin Rex
- [CHANNEL-BINDING] Updates to draft-altman-tls-cha… Nicolas Williams
- Re: [CHANNEL-BINDING] Updates to draft-altman-tls… Alexey Melnikov
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Simon Josefsson
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Simon Josefsson
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to dra… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to Martin Rex
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to Simon Josefsson
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to Martin Rex
- Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to Larry Zhu
- [CHANNEL-BINDING] Avoiding CB sync problem via se… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Eliot Lear
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] Updates to draft-alt… Sean Turner