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

Re: [UPGRADE]: What's left?

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Mon, 09 Mar 2015 15:40:31 -0700
To: Mike West <mkwst@google.com>, Peter Eckersley <pde@eff.org>
Cc: "public-webappsec\@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <yoav@yoav.ws>, Martin Thomson <martin.thomson@gmail.com>
Message-ID: <87pp8hlrq8.fsf@alice.fifthhorseman.net>
On Sun 2015-03-08 04:12:49 -0700, Mike West wrote:
> 1. Upgrade-capable user agent navigates to HTTP: this client should be
> redirected to HTTPS, and HSTS should be asserted.
> 2. Upgrade-capable user agent navigates to HTTPS: this client should remain
> on HTTPS, and that HSTS should be asserted.
> 3. Legacy user agent navigates to HTTP: this client should stay on HTTP.
> 4. Legacy user agent navigates to HTTPS: this client should be redirected
> to HTTP, and HSTS should not be asserted.
>
> My understanding is that the current proposal deals with all of these well
> except #4. Is that an accurate summary?

I think we're assuming here that the site as a whole is fine for
upgrade-capable user agents accessing it for HTTPS.  But individual
resources might be OK or not OK for HTTPS for legacy clients.

Because the specs here involve both per-resource and per-origin
concepts, i think this breakdown is missing another axis: where the
resource requested is fine for legacy clients as well.

In effect, this splits 3 and 4 into two more cases, where the branch we
haven't enumerated covers resources that *should* stay on https (even
for legacy clients), while the site as a whole needs to avoid setting
HSTS for those legacy clients.

A common examples might include web sites where the "admin view" or
"user login page" or "customer account" sections are https.

in these cases, (call them 3a and 4a) we want to keep HTTPS and *not*
assert HSTS for legacy clients.

The implication here is that HSTS is now contingent on the origin/client
interaction, and not just on the origin itself.

       --dkg
Received on Monday, 9 March 2015 22:41:01 UTC

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