Re: Cookies and schemes.

On Tue, Mar 10, 2020 at 3:55 AM Martin Thomson <mt@lowentropy.net> wrote:

> 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'm not sure if, by HSTS, you mean that sites should stick to HTTPS or if
you mean the actual HSTS header. Sites certainly should stop mixing HTTP
and HTTPS, and once they've done that, HSTS is a good thing to deploy. But
I think we should aim to make HSTS less load-bearing. Today HSTS is a
more-or-less frontline defense against all the various cookie mistakes
around partitioning HTTP and HTTPS. This is awkward because HSTS is
stateful and thus a possible tracking vector
<https://webkit.org/blog/8146/protecting-against-hsts-abuse/>, but
mitigations against that risk breaking that defense. If we can bring
cookies closer to the standard origin-based isolation in the rest of the
web, HSTS is no longer needed as a patch for cookies. The remaining use
cases (making sure you are on the correct origin to begin with, and
stricter certificate errors) primarily affect top-level navigations and are
thus more amenable to ideas like
https://github.com/mikewest/strict-navigation-security.


> 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.
>

I see two plausible reasons to want to add some kind of cross-scheme
carveout:
1. as you allude to, providing a low-effort intermediate state for
(insecure) mixed-HTTP/HTTPS sites that would take longer to finish their
HTTPS migration
2. preserving state when an (insecure) fully-HTTP site migrates to HTTPS

On (1), the intermediate state is added fuss because the affected sites
which take advantage of it still need to do the work to migrate to HTTPS.
It also is a risk that we'll be stuck in that intermediate state. Thus I
think it is only valuable if we can get to the intermediate state faster
and the intermediate state is useful in itself. For it to be useful, I
think it needs to be robust against attackers. I'm thus not excited about
anything which keys on redirects because redirects can be faked by the
network. Today, cookies are insecure by default and opt-in secure (if you
use both the Secure attribute and the __Secure- prefix). I think a good
intermediate state would be secure by default and opt-out secure (whether
we spell the opt-out __Non-secure- or Sec-Nonsecure-Cookie or whatever is I
think mostly about the "low-effort" goal, as long as it actually
functions[*] as an opt-out). Then after sufficient time has passed to
reasonably expect a full HTTPS migration, we remove that opt-out, meeting
standard security requirements of the web platform. (Or rather something
closer to it. We'd still have port and eTLD+1 silliness.)

On (2), the thinking would be that sites shouldn't be disincentivized from
migrating from HTTP to HTTPS out of worry of losing all their state. Such a
site might then use the above opt-in path as a one-time migration and then
stop consuming the insecure values after the migration is done. Of course,
they'll do the former but never do the latter, which is why this can't be
there forever. The question then is when would we be okay removing this. I
think that's where the cookie lifetime change fits in. Given that http://
is pronounced "the network", it is not a suitable scope for long-term
state, thus it makes sense to tie the lifetime to some notion of
session—just long enough that the user can still perform continuous actions
to avoid breaking everything. If that sticks, there won't be meaningful
state to migrate to HTTPS in the first place and the need for (2) is
reduced.

David

[*] An example of something which doesn't actually function as an opt-out
would be an Insecure attribute to mirror the existing Secure attribute.
That helps with HTTPS-to-HTTP leaks but it provides no defense against
HTTP-to-HTTPS injection because the network can add that attribute all they
like.