Re: HSTS priming vs preloading

On Tue, Feb 2, 2016 at 2:54 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Feb 2, 2016 at 2:41 PM, Richard Barnes <rbarnes@mozilla.com>
> wrote:
> > That's part of why priming is nice -- it gives you the determinism of
> > preloading, while letting you trade an RTT for not preloading.
>
> Yeah. The main problem with priming is that it gives an attacker a
> chance so it's not a complete alternative and less than ideal when you
> consider navigations as well rather than just mixed content. (It's a
> step up from where we are today, for sure.) And an alternative where a
> browser hosts the preload table would give the browser insight where
> the user is going (and perhaps slow things down unacceptably). Meh.


You could certainly imagine a world where we'd apply the same concept to
navigation. I don't think we're there yet in terms of the user impact, but
it's certainly feasible. Clever browser folks could even integrate such a
check into their prerendering/preloading logic to try to hide the RTT to
the extent possible.

Even in that world, though, an active attacker can intercede by blocking
the TLS connection entirely. I don't have a good suggestion for avoiding
that risk other than preloading.

-mike