Deprecating nonsecure cookie delivery.

[mikewest]

Hello you lovely TAGers, you！

I'm requesting a TAG review of:

• Name: Deprecating nonsecure cookie delivery
• Specification URL: We'd roll it into RFC6265bis, I imagine.
• Explainer, Requirements Doc, or Example code: https://github.com/mikewest/cookies-over-http-bad
• Tests: None yet.
• Primary contacts: @mikewest

Further details (optional):

• Relevant time constraints or deadlines: None.
• I wrote the Self-Review Questionnare on Security and Privacy but haven't filled it out for this proposal.
• I have reviewed the TAG's API Design Principles

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

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

Relevant things you might want to skim through:

• Blink intent thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/r0UBdUAyrLk
• Mozilla's prior art: https://groups.google.com/forum/#!msg/mozilla.dev.platform/OrUOw3ag258/Te3rqqRLAgAJ

[torgo]

@mnot what do you think?

[slightlyoff]

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:

• The word "Chrome" appears a lot...maybe less of that?
• 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?
• 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?

[mnot]

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]

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: mikewest/cookies-over-http-bad@fd77fa3

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]

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]

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]

We will endevour to respond by next week.

[mikewest]

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

[mikewest]

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]

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

[hadleybeeman]

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

[lknik]

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]

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!