On Wed, Nov 5, 2014 at 9:48 PM, Watson Ladd <[email protected]> wrote: > This is different from what appears on Browser-Auth.net in two ways: > the existing TLS client authentication mechanism isn't used, and the > application layer/TLS interaction is new: the TLS implementation must > fish out a signed value represented as application data, or export the > tls_unique binding to let the application verify the binding. This is > underspecified in the draft, which may be okay. (Also underspecified: > referred token bindings)
(Assuming that we're talking about ChannelID and it's successors.) It's based on tls_unique and the extended master secret fix will be required. > One part missing is specifying how to do RSA signatures. Is it PSS or > PKCS 1.5? I hope it's PSS. It's ECDSA at the moment. There's talk of supporting RSA signatures and, if we do that, I very much hope that it'll be PSS. > 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. > > However, what was wrong with OBC which reused existing TLS > authentication mechanisms? Is this something we can fix in TLS 1.3, or > not? TLS client auth is in the clear and renegotiation sucks, thus OBC was born. Around then SPDY was also happening and SPDY can merge several eTLD+1's on the same connection, but there's only one TLS handshake and thus one OBD. So there was a SPDY CREDENTIAL frame added: the client manages a conceptual array of signatures at the server. It can set elements of the array to public keys with CREDENTIAL messages by signing tls-unique. Each request indicates which public key in the array it's linked with. But there was a lull in OBC work and SPDY was growing up from being a Google-internal experiment so CREDENTIAL was dropped. Having both OBC and CREDENTIAL was overly complex but it was thought that many applications wouldn't care about SPDY connection pooling and would want token binding handled at the lower levels of the software stack, so we simplified lots and ended up with ChannelID: https://tools.ietf.org/html/draft-balfanz-tls-channelid-01. ChannelID is like OBC but doesn't take the client-auth slot (which people wanted for other things) and doesn't involve a dummy X.509 certificate. That's live in Chrome at the moment. Now it looking like it really is better to have it just at a higher level and you end up with something like the current token binding drafts. Cheers AGL _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
