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

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

From: Mike West <mkwst@google.com>
Date: Fri, 20 Mar 2015 14:22:15 +0100
Message-ID: <CAKXHy=d2PsBv9mS0DdfjZZva3W8mGsfMbnxKZXB45Lyi08n9oA@mail.gmail.com>
To: Peter Eckersley <pde@eff.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, 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>
On Thu, Mar 19, 2015 at 7:24 PM, Peter Eckersley <pde@eff.org> wrote:

> > 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?
> That's right.  Once an origin is committed to HSTS for every client, the
> header is retired for that origin.

I very much hope we can find new carveouts in the future. It's fairly
utopian to suppose that substantial amounts of traffic will be covered by
this one. :(

> > 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 agree that the existing "preload" directive looks like a better way to
> achieve that.

I've cleaned up the pull request at
https://github.com/w3c/webappsec/pull/209, and merged it into the draft.
This does a few things:

1. Adds `HTTPS: 1` to all outgoing navigational requests that aren't
"preloadable" via the `preload` directive.
2. Drops the `Upgraded: 1` header, as it's a somewhat useless signal if
we're sending `HTTPS: 1`.
3. Adds a number of definitions and brought in a number of HSTS concepts in
order to make some of the explanations more clear.

I'd suggest that we publish a new working draft with this content, and
start experimenting with implementations to see if these things that we've
been talking about are going to effectively meet developers' needs.



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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Friday, 20 March 2015 13:23:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC