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

Re: HSTS Priming, continued.

From: David Illsley <davidillsley@gmail.com>
Date: Wed, 11 Nov 2015 20:05:14 +0000
Message-ID: <CA+E3Fw2OQ=uw7QGgK5q+rYYDZ9GqJ9aTxJZkkFsbooq2F_2Vig@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
https://tools.ietf.org/html/rfc6797#section-7.2 includes:

 "An HSTS Host MUST NOT include the STS header field in HTTP responses
conveyed over non-secure transport."

and https://tools.ietf.org/html/rfc6797#section-8.1 includes:

"If an HTTP response is received over insecure transport, the UA MUST
ignore any present STS header field(s)."

Presumably this is to prevent attackers from being able to poison a UA's
HSTS Policy store where a site doesn't support TLS and cause a denial of

While HEAD requests to / could be special-cased to be processed, but not
actually persisted, it seems like a pretty messy set of logic.


On Fri, Nov 6, 2015 at 2:33 PM, Mike West <mkwst@google.com> wrote:

> The discussion at TPAC more or less convinced me that Richard's HSTS
> Priming proposal is a good one that we should explore. To that end, I put
> together a little bit more detail about what it would mean for Fetch and
> etc. so that we have more details to argue about.
> I'd appreciate it if you'd take a quick look at
> https://mikewest.github.io/hsts-priming/ and give some feedback about
> those details (Note: I think the normative changes should end up in Fetch
> and HSTS and MIX, but it's easier to discuss a single document than a set
> of diffs).
> CCing some folks who I think might be particularly interested.
> -mike
Received on Thursday, 12 November 2015 09:07:42 UTC

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