Re: HSTS Priming, continued.

Trying to sum up / reply to a couple things here:

With regard to scope and goals: Recall that there are actually two goals
here, (1) allowing HSTS to resolve mixed content issues, and (2) generally
discovering HSTS more frequently.  For me, (2) is lovely, but (1) is the
reason we're here.  The reason we got to priming was that some folks
thought that indeterminacy around HTTP vs. HTTPS was blocking on (1).

However, the only issue with indeterminacy is when you don't know if
something's going to load or not.  That is, the indeterminacy only matters
for *blockable* mixed content.  So given the latency concerns, I would
propose that we focus on that case first, and we can expand to other loads
or navigations later if we want.

I would also note that the non-blocking(1) cases are non-blocking(2) and
non-blocking(3)  :)  If you're not going to block the content, you can do
the priming query in parallel to the normal query, and not block the real
load.  That way, you get the discovery benefit (for subsequent loads) with
no latency hit.  And as discussed above, we don't need to block the change
in HSTS treatment based on them.

With regard to a separate priming request vs. just doing the request: A
separate priming request does incur some additional latency, but it's not
enough to matter.  With h2 or even pipelined h1.1, it's exactly 1xRTT,
since you've already got the connection warmed up.  That seems cheap enough
that it's worthwhile to keep things conceptually simpler.

--Richard



On Wed, Nov 11, 2015 at 7:56 PM, Eric Mill <eric@konklone.com> wrote:

> On Wed, Nov 11, 2015 at 6:46 PM, Daniel Kahn Gillmor <
> dkg@fifthhorseman.net> wrote:
>
>> I agree with Martin that for content that would otherwise be blocked, we
>> don't care about the latency.
>>
>
> It'd definitely be a lot less important, but you still might -- user
> perception/reaction to a website that's "still loading" for a long time
> might be worse than to a website that quickly blocked active content and
> visibly completed the loading process.
>
> Not trying to be contrarian -- security is more important than latency in
> the abstract -- just trying to be complete about the tradeoffs.
>
> On Wed 2015-11-11 19:34:00 -0500, Martin Thomson wrote:
>> > If I have this right, your main concern is with the potential delay in
>> > loading passive mixed content.  If we have to wait for a timeout
>> > before falling back, that's pretty unpleasant.  However, I think that
>> > at some point in the future, we may want to take that hit.  Given how
>> > much mixed content there is at the moment, that might not be *right
>> > now*.
>>
>> Alternately, browsers adopting this strategy where UA policy allows a
>> fail-through to cleartext (because "passive" content) could just use a
>> shorter timeout than normal before triggering a fail-through, right?
>>
>> One concern here is that this might touch too many layers to be
>> feasible, since timeouts might be in any or all of TCP session
>> establishment, TLS handshake, HTTP response.
>
>
>> But the browser could presumably just set a timer and say "if this
>> request isn't back and done in K milliseconds, we're going to abort it
>> and kick off an http request".
>>
>
> Yes, and to be clear, these latency issues are still there for HSTS
> priming. I don't see a reference to timeout policy in the HSTS priming
> spec, but a UA would have to decide on an acceptable client-side timeout
> either way before proceeding. So that logic will have to be written either
> way.
>
> HSTS priming mitigates the impact of the timeout process more effectively
> because of its cache (of both positive and negative responses).
>
> -- Eric
>
>
>>
>>     --dkg
>>
>
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
>