On Mon, Mar 9, 2015 at 8:19 AM, Mike West <mkwst@google.com> wrote:
>
> As an aside, it occurred to me overnight that we can avoid the redirect
> (and the signal) for HTTP pages if we interpret the presence of an
> `upgrade-insecure-requests` directive in an insecure response as asking for
> the resource itself to be upgraded. Filed
> https://github.com/w3c/webappsec/issues/212 to explain a bit, and think
> about this some more.
>
"client should behave as though it received a redirect response to
https://example.com/" ... what does that mean exactly? As in, the UA should
treat it as a 302 and transparently initiate a new request? Would it
remember this for subsequent navigations?
Re, avoiding UA sniffing: have you considered an opt-in strategy for
delivering the header? In CH we have "Accept-CH" [1] which acts as a signal
for the UA to advertise its capabilities to the server.. this allows the
site to opt-in without burdening the rest of the web with the same
on-by-default header.
[1]
https://tools.ietf.org/html/draft-grigorik-http-client-hints-02#section-2.2.1
>
>
>> * understand why the tradeoffs and implementation work make sense for
>> their body of legacy content
>>
>> ...then I think they can probably also evaluate the effect of HSTS on
>> their website under these circumstances.
>>
>> This whole upgrade spec is about providing a long-term migration path,
>> right? Where we expect browser update cycles to outpace the ability of
>> a website with a large body of content to go through and upgrade the
>> resource links?
>>
>
> This is a great way of phrasing the way that I've been approaching the
> problem, thanks, Eric!
>
>
>> It could be that the tradeoff here is that HSTS is effectively not
>> advised until the presence of legacy clients that don't support the
>> UPGRADE spec diminishes to an acceptable amount. At that time, a
>> website can shut off the HTTPS->HTTP downgrade, and add HSTS, at the
>> same time. The UPGRADE spec could recommend this strategy.
>>
>
> This is what I was trying to get at in my previous email. I see HSTS as
> putting a cap on an otherwise pristine TLS configuration, and
> pinky-swearing to the user agent that you're going to keep it running for X
> seconds. Given that we're talking about sites that are in the middle of a
> migration process, and that we're presupposing that they're going to have
> both an HTTP and HTTPS version of the site running alongside each other,
> it's not clear that setting HSTS is going to be high on their priority
> lists.
>
> In the other thread, I'm even going to argue that this is an advantage of
> UPGRADE over HSTS2, as the former is representation-specific, which allows
> authors to make granular decisions about which pages can safely be
> upgraded, without locking themselves into something for a long time.
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>