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

It seems that we can leave tls-unique as is, and add a new registry, let's say, called "tls-dynamic" or similar, to use the updated definition. Unless some one finds a case where interop can be an issue, it is probably a better way to go.

--Larry

-----Original Message-----
From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On Behalf Of Simon Josefsson
Sent: Thursday, March 18, 2010 8:22 AM
To: Dave Cridland
Cc: channel-binding@ietf.org; SASL Working Group; tls@ietf.org
Subject: Re: [sasl] [CHANNEL-BINDING] Updates to draft-altman-tls-channel-bindings (PLEASE REVIEW)

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
_______________________________________________
sasl mailing list
sasl@ietf.org
https://www.ietf.org/mailman/listinfo/sasl