Re: [TLS] Deprecating tls-unique for TLS 1.3

[Alexey Melnikov <[e-mail]>]

On 04/11/2015 15:48, Martin Thomson wrote:
> What is wrong with getTlsUnique2() or getBetterTlsUnique() ?

That would be fine, but see below.

> It's not a drop-in replacement,

If it is not a drop in replacement, it should have a different name.
Channel bindings are referenced by names in various protocols (and some
implementations can support more than one channel binding type), in
particular in SASL SCRAM and SASL GS2.

> but it indicates that the app understands the
> change.  Otherwise, we might have to signal this in TLS 1.2 proper.
> 1.3 can just be fixed.

My point are:

1) "tls-unique" is defined in TLS version-independent way, so it is
currently defined for TLS 1.3 (as long as TLS 1.3 still uses Finished
messages).

2) It would be much better to implement a single recommended TLS channel
binding that works for both TLS 1.2 and TLS 1.3

3) We can't redefine how tls-unique works for TLS 1.2 without breaking
existing implementations (I can explain this in more details, if needed).

All of these made me think that defining a new channel binding that
works for both TLS 1.2 and TLS 1.3 would be a better option.

> On 4 November 2015 at 15:42, Alexey Melnikov <[e-mail]> wrote:
>> On 04/11/2015 11:13, Eric Rescorla wrote:
>>> Can you expand on this a bit? Perhaps propose some text.
>>
>> So, tls-unique is defined in RFC 5929 as:
>>
>>    Description: The first TLS Finished message sent (note: the Finished
>>    struct, not the TLS record layer message containing it) in the most
>>    recent TLS handshake of the TLS connection being bound to (note: TLS
>>    connection, not session, so that the channel binding is specific to
>>    each connection regardless of whether session resumption is used).
>>    If TLS renegotiation takes place before the channel binding
>>    operation, then the first TLS Finished message sent of the latest/
>>    inner-most TLS connection is used.  Note that for full TLS
>>    handshakes, the first Finished message is sent by the client, while
>>    for abbreviated TLS handshakes (session resumption), the first
>>    Finished message is sent by the server.
>>
>> This is currently independent of the version of TLS used. This is also
>> broken for TLS 1.2 due to the triple handshake vulnerability.
>>
>> I don't think we can just redefine this for TLS 1.3 and expect this to
>> work, because APIs for getting this information out of TLS libraries are
>> going to be different if Exporters are used.
>> Also, if "tls-unique" is redefined, an old implementation of
>> "tls-unique" would be unable to talk to a new implementation. For
>> example if one end is IMAP client using SCRAM or GS2 against IMAP server
>> implementing the same.
>>
>> I think there is desire to fix this for both TLS 1.2 and 1.3. I think
>> the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03
>> (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I
>> think conceptually what Simon did is very similar to what was proposed
>> in the TLS meeting today.
>>
>>
>>> -Ekr
>>>
>>>
>>> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>     Just to clarify, I think it is fine to define TLS 1.3 replacement
>>>     for tls-unique using Exporters. But I suggest for interoperability
>>>     this should be defined as a new channel binding with a new name, as
>>>     opposed to just redefining tls-unique.
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls