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

On Mon, Mar 16, 2015 at 11:26:09AM +0100, Mike West wrote:

> 
> 1. The things in the upgrade spec happen by default when a page is
> delivered over HTTPS.
> 2. Separately, the HSTS2 header allows sites to lock upgradable folks into
> TLS.
> 
> Is that accurate?

Yes.  There's a unnecessary complexity if the proposals are merged
naively, because there'd be two new headers (upgrade-insecure and
HSTS2).  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'm focused on the opt-in mechanism for the moment, because I think that's
> something we can ship quickly. I think a minimum-viable implementation
> could go out in Chrome 43, we can get some author feedback to see if it
> solves their problems in the ways we expect, and work on solving the
> concerns that remain.
> 
> Does that sound like a reasonable approach from the EFF's perspective?

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

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.

-- 
Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

Received on Monday, 16 March 2015 20:12:26 UTC