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://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
