g 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 a
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 pl
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
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 wrote:
> On 04/11/201
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 T
On 4 November 2015 at 11:16, Yoav Nir wrote:
> 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 s
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 using Exporters. But I suggest
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
> be defined as a new chann
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 mail