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

[Alexey Melnikov <[e-mail]>]

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.