I agree with Alexey that we can't just start returning the new, longer, tls-unique from the same API call.
So perhaps the simplest fix is to update RFC 5929 to say that tls-unique is deprecated and EKM should be used instead, with certain recommended parameters. This does mean that any protocols that rely on tls-unique will need to negotiate a new revision. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Alexey Melnikov Sent: Wednesday, November 4, 2015 4:06 PM To: Martin Thomson <martin.thom...@gmail.com> Cc: tls@ietf.org Subject: Re: [TLS] Deprecating 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 are referenced by names in various protocols (and some implementations can support more than one channel binding type), in particular in SASL SCRAM and SASL GS2. > 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. My point are: 1) "tls-unique" is defined in TLS version-independent way, so it is currently defined for TLS 1.3 (as long as TLS 1.3 still uses Finished messages). 2) It would be much better to implement a single recommended TLS channel binding that works for both TLS 1.2 and TLS 1.3 3) We can't redefine how tls-unique works for TLS 1.2 without breaking existing implementations (I can explain this in more details, if needed). All of these made me think that defining a new channel binding that works for both TLS 1.2 and TLS 1.3 would be a better option. > 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >> ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40mic >> rosoft.com%7c5848f661843a4a6bdf2f08d2e4e676db%7c72f988bf86f141af91ab2 >> d7cd011db47%7c1&sdata=eo0A63TBIz1CdZKzpBRb9o2A7y1CW12IEtXPltbiohY%3d _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c5848f661843a4a6bdf2f08d2e4e676db%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eo0A63TBIz1CdZKzpBRb9o2A7y1CW12IEtXPltbiohY%3d _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
