On Aug 20, 2013, at 9:01 PM, Trevor Perrin <[email protected]> wrote: > On Tue, Aug 20, 2013 at 1:39 AM, Yoav Nir <[email protected]> wrote: >> Hi Trevor. >> >> I think (a) is definitely worth doing, but I also think that (b) can be done >> along the way. > > Interesting... If we were to prioritize them, I'd argue the reverse: > (b) ("Origin Cookies") strikes me as the most economical, since it > fully addresses cookie-forcing and stealing provided TLS is secure.
(a) addresses the cookie-as-bearer-token issue that makes BEAST and CRIME something that people write "The Internet is broken" blog posts about rather than just a curious result that cryptographers and crypto-geeks can get excited about. >> Is there some reason why (a) and (b) can't be requirements filled by a >> single mechanism? > > That's exactly what Smart Cookies attempt - they have origin-binding, > *and* cryptographic-binding via MAC. > > But I don't know whether that's the best approach. It might be easier > to push things like ChannelID and Origin Cookies separately. > > >> Regarding smart cookies vs channel ID: Not changing TLS is a definite >> advantage of Smart Cookies. Reading that message again ([1]), I'm not sure >> whether the cookie_binding is necessary, > > It's necessary so the transmitted MAC doesn't become a "bearer token" > that could be re-used by anyone. But you bind the transmitted MAC to the TLS session by getting cookie_key extracted from the session. So what you transmit is not a bearer token, as it can't be used in another session. The cookie_binding protects you against someone stealing the cookie during set-cookie, but that's a one-time thing, although it could be worth it. >> but I get that it protects against passing cookies. The only issue I have >> with this >> is that it relies on extractors, and so will break at TLS proxies. While >> this is good >> from a security perspective, it's a killer for deployment. I think that >> Channel ID >> works in the presence of proxies, assuming the proxies are updated and move >> the encrypted extension unchanged. > > I assumed that both Smart Cookies and ChannelID would break at TLS > proxies until those proxies are updated to pass some information > downstream. And then would work. If Channel ID becomes part of TLS 1.3, proxies would have to be updated. No question there. But once it is, then the new handshake records can just be passed along by the proxy. What the proxy can't do, is to make it so that the master secret on both halves of the connection are the same. The proxy performs a handshake with the client and with the server, and then decrypts and re-encrypts everything. So there is no way that the client and server can calculate the same values for cookie_binding and for cookie_key. > Since Smart Cookies don't affect the bytes-on-the-wire, whereas > ChannelID modifies the Handshake protocol, I was also assuming Smart > Cookies would be the easier change. > > Is that wrong? It is an easier change, but I don't see how you can get it to work through a proxy. Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
