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

On Mon, Mar 16, 2015 at 9:11 PM, Peter Eckersley <pde@eff.org> wrote:

> Unless the transition from upgrade-insecure to
>
upgrade-insecure-by-default was swift, well-informed websites would want
> to send the CSP header for a long time, even though it was the default
> behaviour of most clients.
>

I think getting "most clients" on board "swift"ly is going to be difficult.
I also think that legacy browsers are going to be around long enough to
make it unlikely that folks can cleanly rely on new default behaviors
without doing some work.

You have a better sense of what's doable quickly in Chrome than I do
> :). *If* upgrade-insecure can ship quickly, and
> upgrade-insecure-by-default cannot, even as a cohorted / experimental
> feature, then let's follow your plan


Making the behavior opt-in is a conservative, safe option that I believe I
can sell to Blink's API owners. It leaves room for radical, risky
experiments in parallel, but won't break any Forbsean sites that do strange
things for strange reasons.

It does less than you want, but significantly more than nothing, and seems
like the right compromise approach to get things started. Getting something
out into developers hands now seems like the best way to evaluate whether
the impacts we're discussing here actually matter to developers interested
in deploying the feature.


> supplemented by either an improved #209 or some concretised version of
> #212 (whose full impact in terms of possible extra bytes from Location:
> headers, extra roundtrips, and additional cookie and page content exposure
> I don't fully understand yet).


The spec as-written handles the core use-case of upgrading HTTP to HTTPS by
unconditionally sending a `Prefer` signal along with insecure navigational
requests to which the server can respond with a redirect. It does not
attempt to handle downgrading HTTPS to HTTP for upgrade-incapable clients,
nor does it attempt to handle setting HSTS for upgrade-capable clients.

On the issue of downgrades: I'm reluctant to add a header to every secure
navigational request as well (as suggested in
https://github.com/w3c/webappsec/pull/209), as I don't see how we'd ever be
able to remove them once added. I agree that the downgrade procedure I
proposed in https://github.com/w3c/webappsec/issues/212 is nuts. I don't
have a good answer here other than UA sniffing (which, really, I don't
think is that bad of an option).

HSTS is something for which I think we can add a reasonable workaround: if
we add an `upgraded: 1` (or similar) signal when we actually upgrade a
resource (as proposed as part of https://github.com/w3c/webappsec/issues/212),
then you can safely send `Strict-Transport-Security` along with the
response to an upgraded request. That has the advantage of a) going away
over time as folks edit their pages for legacy support, and b) applying
only to sites that request upgrades. The more I think about it, the more I
think we should add this: I've poked at it in
https://github.com/w3c/webappsec/commit/05e5358eddcce3981a9f1afc5ff31bebc568cfb4.
Alternate spelling suggestions welcome. :)


> If there's a way that we could start upgrade-insecure-by-default as a
> cohorted experiment that becomes universal in a release or two, I think
> we should consider that path, since it fixes more sites and makes
> everything simpler for developers.
>

I suspect that "universal" is unlikely to happen in a release or two among
the evergreen browsers, and I don't think the
locked-into-a-version-of-IE-at-work market is going away.

It might be helpful if other browser vendors would weigh in regarding their
likelihood to implement something along the lines of what we're discussing
(+David/Crispin from Microsoft, +Tanvi/Dan from Mozilla (Hi!)), but I doubt
anyone is going to commit to near-future timelines for the behavioral
change you're looking for.

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