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 <martin.thom...@gmail.com > <mailto:martin.thom...@gmail.com>> wrote: > On 4 November 2015 at 11:16, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> 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 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. > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
