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

Re: HSTS Priming, continued.

From: Brian Smith <brian@briansmith.org>
Date: Wed, 11 Nov 2015 11:35:36 -1000
Message-ID: <CAFewVt4GRpa2mEPxUiN4-6ETka7u8nSU_YCNQB5knt0ZGGf5ow@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Crispin Cowan <crispin@microsoft.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Richard Barnes <rbarnes@mozilla.com>, Jeff Hodges <jeff.hodges@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
On Wed, Nov 11, 2015 at 11:30 AM, Brad Hill <hillbrad@gmail.com> wrote:

> A nice benefit of the priming approach for HSTS is that you do receive a
> durable signal which the browser can cache,

HSTS is cached for the entire origin, regardless of which resource it comes

> and which can prevent downgrade attacks on subsequent connections.

This is the same in both approaches.

> Also consider that some sites may not set HSTS for every response, but
> only for well-known app "entry points" (to optimize network traffic).

Does this still matter, performance-wise, for HTTP/2 connections, given
header compression? Just send the HSTS header for all resources for HTTP/2
connections and rely on compression to work. Browsers that would support
HSTS priming also support HTTP/2 and HTTP/2 header compression.

Conversely, consider a server that never expects a request to "/" and so
never sets the HSTS header field (e.g. because it forgot to put the HSTS
header field on its error responses, which is a very common failure mode).

Also, consider that many servers don't implement HEAD correctly.

Received on Wednesday, 11 November 2015 21:36:05 UTC

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