On Thu, Jul 11, 2013 at 5:50 AM, Yoav Nir <y...@checkpoint.com> wrote:
> > On Jul 11, 2013, at 12:32 AM, Trevor Perrin <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" or "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. > That's true, but is it important? If a site can't be bothered to deploy TLS, is it going to deploy a new session management mechanism? The security gain of improving cookies without deploying TLS seems small - it might protect cookies at "http://example.com"; from someone who hacks " http://test.example.com";, but that's about it. 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. > ChannelID solves this problem. The goal of BEAST, CRIME, or other forms of cookie theft is to steal a *usable* cookie. With ChannelID, the channel-bound cookie that an attacker might steal is unusable. 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. > Deriving new cookie values based on where the cookie originated and where it is being sent is one approach. But making cookies sent to a particular client untransferable to other clients seems equally valid, and is simpler if you can rely on something (eg "ChannelID") to securely differentiate clients. Trevor
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
