On Jul 11, 2013, at 12:32 AM, Trevor Perrin <tr...@trevp.net<mailto:tr...@trevp.net>> wrote:
ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | "google.com<http://google.com/>" or "gmail.com<http://gmail.com/>"). - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the working group choose? - Will you be willing to review the solution document? I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better. Hi Trevor [wearing no hats] ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. OTOH a proposal that hashes some header fields with a secret value works with or without TLS. But even if we restrict our solution to HTTPS, I don't see how ChannelID helps a problem like the BEAST and CRIME attacks. In both cases, the issue is the scoping of cookie use. An attacker's web page or script can cause the UA to send requests of the attacker's choosing to a server. This has nothing to do with TLS - this in an HTTP behavior. As it is, if I visit a website that has <img src="https://mail.google.com/gaaaaaaaaaah";> my UA is going to send a request to mail.google.com<http://mail.google.com> for "gaaaaaaaaaah", and that request is going to have my cookie. I don't see what ChannelID adds here. With channel-bound cookies (section 7.1) my UA will send the same request to mail.google.com<http://mail.google.com>, but with a channel-bound cookie. But since it's my valid channel, the server will accept it just the same. What we need, IMO, is a new cookie with new rules, such as that cookies will be indexed by origin and refer(r)er so that my UA would use different cookies for requests stemming from pages from google and requests initiated by pages and scripts from other origins. This kind of rule change is more important than either the crypto binding or the request hashing. Yoav
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
