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 <alexey.melni...@isode.com> wrote: > 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 >> <alexey.melni...@isode.com <mailto:alexey.melni...@isode.com>> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
