W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: HSTS priming vs preloading

From: Richard Barnes <rbarnes@mozilla.com>
Date: Tue, 2 Feb 2016 08:41:20 -0500
Message-ID: <CAOAcki9Ly9rF-Ctp8r47WU8FMFnXOV7XiOj4=hP9qe0uzYbE+g@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Eric Mill <eric@konklone.com>, Ben Wilson <ben.wilson@digicert.com>, Jim Manico <jim.manico@owasp.org>, Mike West <mkwst@google.com>, Jim Manico <jim@manicode.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Feb 2, 2016 at 4:00 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Feb 1, 2016 at 11:27 PM, Eric Mill <eric@konklone.com> wrote:
> > However, the underlying issue driving HSTS priming (and why the HSTS
> check
> > currently comes after mixed content checking) is to make it so users have
> > deterministic and consistent experiences. Since preloading also
> guarantees
> > that consistency, you could also imagine an interim step being taken,
> before
> > this priming proposal is finalized and before the priming ping is
> > implemented anywhere, where preloaded HSTS is put ahead of mixed content
> > checking.
>
> I think there are two issues with this:
>
> 1. Last I heard some software, e.g., Firefox OS, did not perform
> preloading due to the size of the table.
> 2. What happens if large host providers bundle LE / HSTS / preload?
> Scaling the preload system is a good problem to have, but it seems
> like we need something there if we are going to make it part of the
> way other standards work.
>

That's part of why priming is nice -- it gives you the determinism of
preloading, while letting you trade an RTT for not preloading.

--Richard


>
>
> --
> https://annevankesteren.nl/
>
Received on Tuesday, 2 February 2016 13:41:51 UTC

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