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

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 wrote: > > Just to clarify, I think it is fine to define TLS 1.3 replacement for > tls-unique

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

Can you expand on this a bit? Perhaps propose some text. -Ekr On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov 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

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

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

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

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

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

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. On 4 November 2015 at 15:42, Alexey Melnikov