Re: [UPGRADE] Consider plan B for reduced complexity?

On 17 March 2015 at 18:12, Peter Eckersley <pde@eff.org> wrote:
> I've updated the #209 pull request to create an eventual path toward
> retirement of the header, once sites deploy HSTS.
>
> WDYT about that solution?  It seems to have about the same retirement
> properties and horizon as #212, without being quite as nuts.

Maybe you could summarize the solution so we don't have to go
grovelling around in diffs of HTML to make sense of it.

What I'm reading is:

1. if you have the csp directive set, make the http:// requests anyway, but
2. add a prefer: foo header to http:// requests (all requests, or just
subresources? :p )
3. sites can redirect those http:// requests to https:// based on the
presence of prefer: foo
4. the redirected request will ALSO have the prefer: foo header field
5. sites that see prefer: foo over https:// can set HSTS (if that's
save to do for the entire site, I guess)

The idea being that nothing special happens unless the UA supports
this mechanism.  And then, only as long as they are willing to make
that initial request in the clear.  Once that is gone and we are in
whatever utopian future doesn't have http:// any more, it's OK to drop
the prefer: foo.

You note that you could drop prefer: foo on some requests once you
have HSTS, but that means that sites won't be able to refresh the HSTS
state.  I'm not sure about the suppressing until 3/4 of the duration,
but the exact figure can be bike-shedded later or left to
implementations to decide.

I guess if a site goes full-HSTS, prefer: foo goes away too, but I
can't see how to detect that.  Vary: prefer might be used (actually
it's arguably needed) as a signal there.

(Prefer: tls carries the wrong connotations, I think.)

Received on Wednesday, 18 March 2015 04:28:19 UTC