On Thu, Nov 6, 2014 at 11:28 AM, Andrei Popov <[email protected]> wrote: >> Also, on use of ALPN: Stuff like this (combined with some other proposals) >> is exactly what I had in mind when I said that using ALPN for feature >> negotiation does not scale. > True, this is less than ideal today, and will be more of an issue in the > future if there is interest in supporting Token Binding with more application > protocols, and/or more key types. The TLS WG could then define ALPN/2 with > structured IDs, but this feels like a separate discussion. Some other > application protocols, as well as Token Binding, could benefit from > structured ALPN IDs, but on the other hand negotiating application parameters > within the TLS handshake has its architectural drawbacks.
Thanks to AGL and Andrei for filling me in. I just realized that this design is incompatible with 0-RTT, unless we define some sort of unique binding that isn't that comes from the 0-RTT trip (say whatever is used to prevent replays) But now a client needs to recompute the Token Binding when the 0-RTT handshake fails. Or are we willing to eat the latency here? I'm still thinking hard about this whole subject: I can see some potential security issues involving repeated parsing of bound tokens. Sincerely, Watson ladd > > Cheers, > > Andrei > > -----Original Message----- > From: Uta [mailto:[email protected]] On Behalf Of Ilari Liusvaara > Sent: Thursday, November 6, 2014 4:54 AM > To: Watson Ladd > Cc: [email protected] > Subject: Re: [Uta] Understanding Token Binding > > On Wed, Nov 05, 2014 at 09:48:53PM -0800, Watson Ladd wrote: >> >> I want to make sure I understand the big picture of Token Binding and >> why it works the way it does: in particular, it replaces the TLS >> client authentication mechanism with a new one. > > It does not replace TLS client authentication. > >> I don't see any obvious security problems, and I can see some real >> deployment advantages: certificate privacy is preserved without >> renegotiation, and this works just like cookies for the web app >> developer, assuming there is enough work done by the web server. The >> UI advantage is not trivial. > > I do see obvious security problems, but those problems already exist and this > does not make those problems any worse. > >> However, what was wrong with OBC which reused existing TLS >> authentication mechanisms? Is this something we can fix in TLS 1.3, or >> not? > > IIRC, wanting to leave the existing TLS auth "field" to other purposes (I > don't recall exact reasons, I think those were covered in some IETF meeting). > > > Also, on use of ALPN: Stuff like this (combined with some other > proposals) is exactly what I had in mind when I said that using ALPN for > feature negotiation does not scale. > > > -Ilari > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
