Re: [TLS] [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: 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 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>, SASL Working Group <sasl@ietf.org>, Nicolas Williams <Nicolas.Williams@sun.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [CHANNEL-BINDING] [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 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