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

On Wed, Mar 18, 2015 at 5:56 PM, Peter Eckersley <pde@eff.org> wrote:

> 1. to trigger HTTP->HTTPS upgrades for sites that will need the
> upgrade-insecure mechanism
>

I think there's broad agreement that we want a signal for this case.

Note: I still believe that we can get away without this signal (per the
HTTP->HTTPS client-side-redirection spelled out in
https://github.com/w3c/webappsec/issues/212#issuecomment-78011188), but
it's not clear that there's agreement amongst folks who know more about
HTTP than I: Ilya is against that mechanism, mnot seemed fine with it. The
downgrade mechanism in that same comment is clearly terrible: consider it a
failed thought experiment. :)


> 2. to conditionally and safely set HSTS only for clients that support
> the mechanism
>

I think this is doable by sending an `Upgraded: 1` signal only for upgraded
requests, as outlined elsewhere in this (now sprawling!) thread:
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0124.html.
This has the advantage of the overhead being opt-in, and disappearing
naturally as a site migrates its resources from HTTP to HTTPS, at which
point it can serve HSTS unconditionally.


> 3. to trigger downgrades from HTTPS->HTTP for clients that are likely to
> experience mixed content breakage
>

Given this use-case, I don't understand how we'll ever be able to retire
the header. It doesn't seem possible to distinguish between legacy users
whose UA doesn't support the upgrade mechanism, and totally up-to-date
users on the other hand, without adding some information to the request.

I think the `mixed-safe` directive is supposed to address this somehow, but
I don't completely understand the mechanism. Is it basically an assertion
that the website isn't going to be using the upgrade mechanism? If so,
perhaps we could reuse the `preload` directive proposed at `
https://hstspreload.appspot.com/` rather than inventing something new. The
thought would be that if you're willing to ask for anyone and everyone to
preload your HSTS preference, you can't be terribly concerned about the
specific capabilities of the client doing the preloading.

I believe Mike has been reluctant to upgrade the first request because
> he doesn't want to duplicate HSTS, doesn't want the housekeeping of a
> per-domain state to keep track of,


It's not clear what you mean by "first request" here. If you mean the
mechanism spelled out in https://github.com/w3c/webappsec/issues/212, then
I'm not against it at all, as noted above. :)

Not requiring the implementation complexity of wiring up and storing
another per-host flag is an added benefit, but a pretty selfish one. :)


> and (perhaps) wants to preserve the
> ability to deploy on some subset of resources on an origin, though the
> navigational upgrades complicate that a little.
>

Assuming that a site has some subset of resources that simply can't (yet)
be served over HTTPS, with or without the upgrade mechanism, I'd suggest
that they should be able to unconditionally downgrade requests to HTTP,
just as they can now (that is, we'd upgrade a navigation from
http://example.com/ to https://example.com/ client-side, and the server
would respond with a redirect). We shouldn't remove that privilege unless
and until they ask us to by sending an HSTS header.


> > (Prefer: tls carries the wrong connotations, I think.)
>
> The header now seems to be HTTPS: 1
>
> https://github.com/w3c/webappsec/issues/216


Given this week's track record, It'll probably be spelled differently again
tomorrow. :)

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)