Re: [UPGRADE]: What's left?

On Fri, Mar 6, 2015 at 6:49 PM, Peter Eckersley <pde@eff.org> wrote:

> The first significant issue we spotted is that the client will
> (unfortunately) need to keep signalling whether or not it supports this
> mechanisms even over HTTPS requests.  The reason is that in many cases
> HSTS needs to be set conditionally on this feature.
>

I don't understand why HSTS needs to be conditionally set. Presumably
you're only redirecting "safely upgradable requests" to HTTPS if you're
this spec's target audience.

I'm quite uninterested in adding perpetual cruft to the platform. Could you
explain the goals you have in mind? Perhaps there's another way of
achieving them (for example, we could expose something like a
`navigator.hstsEnabled` boolean to express our capability, which clever
authors could use to trigger an HSTS-setting request (although,
realistically, no one is ever going to do that (at least no one for whom
Let's Encrypt's total automation of everything would be suitable))).

We've put together a pull request for this change:
>
> https://github.com/w3c/webappsec/pull/209


Thanks, that makes things easier to talk about!

Unfortunately that does mean this mechanism is going to add a lot of
> bytes on the wire, and we should consider mitigations like shortening
> the Prefer: header, or only sending the Prefer: header for magic HTTPS
> URLs like favicon.ico (since it's just going to be there to refresh
> HSTS once every so often).


+Ilya and Yoav, who are poking at me about bytes on the wire in a separate
thread. I assume they have thoughts that are relevant here. :)

-mike

--
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.)

Received on Friday, 6 March 2015 18:44:44 UTC