W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

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

From: Peter Eckersley <pde@eff.org>
Date: Tue, 17 Mar 2015 18:12:56 -0700
To: Mike West <mkwst@google.com>
Cc: David Walp <David.Walp@microsoft.com>, Tanvi Vyas <tanvi@mozilla.com>, Crispin Cowan <crispin@microsoft.com>, Dan Veditz <dveditz@mozilla.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eric Mill <eric@konklone.com>
Message-ID: <20150318011256.GF881@eff.org>
On Tue, Mar 17, 2015 at 10:06:02AM +0100, Mike West wrote:
> 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'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.

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

UA sniffing is a survivable hack for sites that just want to do
HTTPS-for-new-client, HTTP-for-old, but it's rather dangerous in
combination with HSTS.  Fortunately the user populations that tend to
mess with UA switchers also probably tend to update their browsers, but
I'm sure there'll be lots of complaint emails from exceptions.

And having that impediment to HSTS deployment would be a bad thing,
because it would leave a lot more sites vulnerable to first connection
hijacking and to cookie theft attacks.

Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993
Received on Wednesday, 18 March 2015 01:13:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC