Re: Cookies and schemes.

On Tue, Mar 10, 2020, at 18:29, Mike West wrote:
> 1. Perhaps we do this kind of thing only for a specific endpoint 
> (`/.well-known/migrate-nonsecure-cookies`, for example)?

Eww.  More seriously, I can't see this fitting with existing needs very well.

> 2. Perhaps we prefix the non-secure cookie names with `__Non-secure-` 
> rather than minting a new header?

That might work.  It's new mechanisms, but not new-header-field new mechanisms.  More below.

> Ideally, the load-balancing case devolves to the LB doing an immediate 
> redirect to HTTPS, and then deciding which backend the user should 
> stick to in that secure context. I don't think we should add new 
> attributes in order to support sites that push users back and forth 
> from HTTPS to HTTP.

Yes. HSTS is the only path that has long-term legs here.  If port 80 wants to do some setup for port 443, that's not terrible, but ultimately I think we need to have servers prepared for the first connection arriving on 443.

I'd like to understand more of why there might be multiple cleartext redirects involved.  Or why it might be desirable to not include cookies in all of those responses.

To that end, anything we do here will apparently cause immediate bustage, with the possible exception of what I proposed (absent multiple redirects being involved).

You might annotate those with tags that indicate their shaky status as a warning, but I expect that anything that isn't bustage will be roundly ignored.  So moving them, either by changing their name or putting them in a new header field, does have the effect of causing sites to pay attention.  But flat-out removing the cookies would also have a similar effect and that is the end goal.

The only value to moving them is that maybe servers can salvage something from this quickly and without a ton of extra engineering.  I think that the prefix is the most likely to be conducive to some form of salvage, but I would want to hear that this is necessary and easy before we get into a multi-stage deprecation process.

Received on Tuesday, 10 March 2020 07:51:44 UTC