Re: HSTS Priming, continued.

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

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

David

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
>