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

[Andrei Popov <[e-mail]>]

I agree with Alexey that we can't just start returning the new, longer, tls-unique from the same API call.

So perhaps the simplest fix is to update RFC 5929 to say that tls-unique is deprecated and EKM should be used instead, with certain recommended parameters. This does mean that any protocols that rely on tls-unique will need to negotiate a new revision.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Alexey Melnikov
Sent: Wednesday, November 4, 2015 4:06 PM
To: Martin Thomson <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3

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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>> ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40mic
>> rosoft.com%7c5848f661843a4a6bdf2f08d2e4e676db%7c72f988bf86f141af91ab2
>> d7cd011db47%7c1&sdata=eo0A63TBIz1CdZKzpBRb9o2A7y1CW12IEtXPltbiohY%3d

_______________________________________________
TLS mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c5848f661843a4a6bdf2f08d2e4e676db%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eo0A63TBIz1CdZKzpBRb9o2A7y1CW12IEtXPltbiohY%3d