search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
326 stars 55 forks source link

Deprecating nonsecure cookie delivery. #239

Closed mikewest closed 6 years ago

mikewest commented 6 years ago

Hello you lovely TAGers, you！

I'm requesting a TAG review of:

Further details (optional):

We'd prefer the TAG provide feedback as (please select one):

Relevant things you might want to skim through:

torgo commented 6 years ago

@mnot what do you think?

slightlyoff commented 6 years ago

Hey @mikewest!

We discussed at today's F2F and really like the approach. We'd love to hear back about how the experiment goes! A few minor things came up reading the Explainer:

mnot commented 6 years ago

This has been discussed for a long time in the various ways. Current thinking in HTTP WG is here, although I'm sure folks would welcome further discussion / modification if a consensus position can be found.

Generally, this is fairly easy to justify in the IETF.

mikewest commented 6 years ago

The word "Chrome" appears a lot...maybe less of that?

This started as an internal doc, and you're right that I should have fixed a few more of those references: https://github.com/mikewest/cookies-over-http-bad/commit/fd77fa3116dfdc58dbf4477c655c800faac07081

Have you discussed, or is it the intent, that this would be paired with a flip from insecure to Secure-flagged cookies by default at some date in the future? Or is the addressed in the discussion of hiding vs. deleting?

I think this will indeed depend on the exact mechanism that we end up choosing to run with. I still prefer the simplicity of removing the cookie entirely, as that seems easiest to reason about, both from the browsers' and developers' perspective, but I look forward to the discussion.

Would it be possible to identify a tipping point at which we should make it hard (impossible?) to mint new insecure cookies? Do you have thoughts on that?

It should be possible, yes. And I do have thoughts! If it turns out that folks are generally on board with the idea (and the initial round of feedback is sounding good), my next step is to work out a more detailed schedule with vendors and developers that we think sounds reasonable. Chrome's "HTTP Bad" project took ~2-3 years, as a benchmark...

In my dreamy world of dreams, I could imagine ending up with something like starting with a maximum lifetime of ~a year, and chopping 6 weeks off of that with every browser version until we end up at something suitably small. So, this time next year, non-securely delivered cookies could live for ~6 weeks. Moving from ~6 weeks to ~0 weeks will probably take another year. I'm not sure how we'd wrangle that kind of schedule with vendors that have a more-than-6-week release cycle, but I'm sure we'll work something out. :)

This has been discussed for a long time in the various ways. Current thinking in HTTP WG is here, although I'm sure folks would welcome further discussion / modification if a consensus position can be found.

I fully intend to send this to the HTTP WG in the form of an ID (and I see it as somewhat critical to RFC6265bis, as it otherwise has no story for pervasive monitoring). omnomnom is of course an inspiration for this approach, and I hope this feels like a natural extension of @martinthomson and @cpeterso's existing work (actually, I'd love to collaborate with them on a draft if they have some free time, since it's pretty clear that I'm bad at writing drafts these days... (he says, hopefully?)).

martinthomson commented 6 years ago

I think that this is probably something we can explore. I'm a little concerned about the effect on the integrity of cookies as a set by this sort of change though. The value might have been refreshed recently enough that the site has an expectation that it remains good - at least in relation to other cookies. Eviction like what is proposed could create sudden integrity compromises.

We've explored the idea of cutting cookies before their time in various ways (see httpwg/http-extensions#494 for our conclusions there). All run afoul of the global state integrity issue, namely that killing one piece of state might affect the interdependent pieces of the whole. It's hard to formulate a question that might allow us to gain insight into the effect that might have though. You speculate that cookies are fragile enough that this won't cause much breakage. But this could trigger an eviction of a cookie that HTTPS sends and depends on, so we would have to worry about that too.

Rotating the value as a way to avoid this eviction might undermine the intent. A tracker only needs to periodically flip an insignificant bit to avoid eviction.

As a defense against pervasive monitoring, this might overstate things a little. This method is only effective if you can synchronize evictions across all cleartext activity.

mikewest commented 6 years ago

Thanks, @martinthomson!

I'm a little concerned about the effect on the integrity of cookies as a set by this sort of change though.

This is my biggest concern with the proposal, and I agree it's something to be worried about. We'd end up breaking off a piece of a site's configuration, putting it into a state it doesn't expect. My intuition is that this is a low practical risk, but it's a very real concern. I don't think it's one that's terrible amenable to intuitions, though: my aim is to run some experiments in Chrome to verify that this approach is as deployable as I hope it will be.

Rotating the value as a way to avoid this eviction might undermine the intent. A tracker only needs to periodically flip an insignificant bit to avoid eviction.

Over time, I'd hope that the goal would be to bring the lifetime down significantly. Flipping a bit once a year is trivial to do invisibly. Flipping a bit daily is less trivially invisible.

As a defense against pervasive monitoring, this might overstate things a little. This method is only effective if you can synchronize evictions across all cleartext activity.

As long as folks are still signed-in over HTTP, it's going to be very difficult indeed to substantially mitigate pervasive monitoring. A not-so-secret goal here is to put pressure on not-so-pervasive monitoring programs like advertising networks in order to reduce their impact on developers' ability to migrate to encrypted transport, on the one hand, and to put pressure on sign-in systems on the other for the same reasons.

torgo commented 6 years ago

We will endevour to respond by next week.

mikewest commented 6 years ago

It's next next week, and this is marked "pending external feedback". Is there anything you need from me?

mikewest commented 6 years ago

Ping, @torgo, @dbaron. Is this something y'all will have an opinion on at some point? Clever folks on our networking team are (understandably) reluctant to take on more behavioral differences between Chrome and other vendors without some indication that there's broader theoretical support.

mnot commented 6 years ago

@mikewest do you still intend to bring this to the HTTPWG?

hadleybeeman commented 6 years ago

Explicitly linking this to our issue on @mikewest's proposal to deprecate cookies (Tightening HTTP state management).

lknik commented 6 years ago

Good idea @hadleybeeman though I believe deprecating non-https cookies is to be shipped first. Though on the other hand, not sure of @mikewest plans.

hadleybeeman commented 6 years ago

Hi @mikewest! We discussed this in our meeting today.

We are in favour of this, and I personally am keen for you to crack on and keep going in clearing up the cookie landscape. We'll keep an eye on your other proposal as well. As always, let us know if we can help!