Hi Trevor. I think (a) is definitely worth doing, but I also think that (b) can be done along the way. Is there some reason why (a) and (b) can't be requirements filled by a single mechanism?
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, 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. Yoav [1] http://www.ietf.org/mail-archive/web/websec/current/msg01729.html On Aug 20, 2013, at 3:44 AM, Trevor Perrin <tr...@trevp.net> wrote: > To pick this up again, it would be great to have: > > (a) Some cryptographic binding for cookies, either using asymmetric > crypto (ChannelID) or symmetric (Smart Cookies), to prevent them being > useable when transferred between browsers. > > (b) Some origin-binding for cookies to prevent them leaking to > subdomains and being forced by other domains (Origin Cookies). > > > Both (a) and (b) address the threats of cookie-forcing and > cookie-stealing, but neither is a complete replacement for the other: > > (a) Cryptographic binding of cookies would not prevent an attacker > who controls related domains from: > - deleting cookies > - stealing a cookie from user A and then forcing it back to A, > later, to roll-back the cookie to an earlier value > > (b) Origin binding of cookies would not protect against a failure in > TLS confidentiality that exposes the cookie's value. > > > Questions > ========= > * Are both (a) and (b) worth doing? Should we prioritize one? > > * Regarding ChannelID vs Smart Cookies: ChannelID provides a > "bindable" identifier that could be used for other things besides > cookies (OAuth tokens? other?). But it also requires TLS changes and > an additional signing operation on the client. The Smart Cookie > approach is more efficient but also narrowly scoped to cookies. > > Do people have other arguments, or strong feelings, one way or the other? > > > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
