On Wed, Jul 10, 2013 at 2:39 PM, Nico Williams <n...@cryptonector.com>wrote:
> On Wed, Jul 10, 2013 at 4:32 PM, Trevor Perrin <tr...@trevp.net> wrote: > > Hmm, it's surprising there's no discussion of cookie scoping problems > like: > > - "cookie stealing" via MITM-created subdomains [1], or > > - "cookie forcing" via attacker-controlled sibling or cousin domains [2] > > There's minimal discussion of the concept of "origin"; it clearly > needs more text. I'd love to receive some suggestions for such text > :) I'm not volunteering! It's complicated... > > Also: despite mentioning a few proposals, there's no mention of > ChannelID / > > Channel-bound cookies [3]. > > > > 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"). > > There's definitely mention of channel binding. Channel bound cookies > used over HTTPS would meet the requirements of this spec, except for > the CRIME/BEAST resistance part. > Are you sure about that? I meant "channel-bound cookies" as defined in the ChannelID draft. Even if an attacker stole such cookies via BEAST / CRIME / whatever, the cookies would be unusable without the browser's ChannelID private key for that site. > I'm not sure that we should mandate CRIME/BEAST resistance -- TLS > should arguably be able to resist such attacks. But it will take a > long time to deploy TLS that does, and that's what makes it appealing > to have CRIME/BEAST resistance in the session continuation protocol. > Hmm, haven't browsers already deployed BEAST / CRIME / etc countermeasures? I actually think that TLS-layer fixes to TLS problems are going to be faster, easier, and more comprehensive than trying to get thousands of websites to change how they manage sessions. But the cookie-scoping problems will still exist, so cookies definitely need improvement. For that, ChannelID still seems like the best proposal out there. Trevor
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
