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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 Nov 2015 11:12:50 +0900

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.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Nov 2015 11:13:53 +0900

Can you expand on this a bit? Perhaps propose some text.

-Ekr

On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Nov 2015 11:16:04 +0900

Can’t we just say that all previous uses of tis-unique will instead get an exporter generated with the label “tis-unique” ?

> On 4 Nov 2015, at 11:12 AM, Alexey Melnikov <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Nov 2015 15:00:23 +0900

> Can’t we just say that all previous uses of tis-unique will instead get an exporter generated with the label “tis-unique” ?

That was my thought here: redefine what it means to generate tls-unique.

That's part of why I asked about the size.  We should ensure that
clients are not made sad if they receive a tls-unique that is longer
than 96 bits.

We could backport this to 1.2, but I'm not sure whether this is a new
feature or whether it's a bug fix.  If it is the former, I'm not that
enthusiastic about a backport.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 Nov 2015 15:42:32 +0900

> 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
> <[email-masked] <mailto:[email-masked]>> 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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Nov 2015 15:48:07 +0900

What is wrong with getTlsUnique2() or getBetterTlsUnique() ?  It's not
a drop-in replacement, 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 Nov 2015 16:05:41 +0900

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

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.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 4 Nov 2015 08:30:24 +0100

Despite the proposed extended master secret fix in RFC7627, I now think that tls-unique needs
to be deprecated for all versions of TLS, and that we should design and recommend
a new channel binding that can be used uniformly by SASL/TokenBinding/FIDO etc.

I have read Simon’s draft and it is a plausible approach https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 <https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03>
The TokenBinding folks have gone with an exporters-based binding, which makes sense too.
Both of them rely on the session hash construction and should be compatible with TLS 1.3.
One question to ask is whether the binding should be per-session (i.e. per master secret) or per-connection.

Best,
Karthik

> 
> On Wed, Nov 4, 2015 at 7:00 AM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> On 4 November 2015 at 11:16, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 4 Nov 2015 08:43:17 +0000

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:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Wednesday, November 4, 2015 4:06 PM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3

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.

>> 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.
>> example if one end is IMAP client using SCRAM or GS2 against IMAP 
>> server implementing the same.
>>
>> (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
>>>
>>>
>> 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
[email-masked]
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