Re: [UPGRADE] Consider plan B for reduced complexity?

On Wed, Mar 18, 2015 at 1:50 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> You seem to be assuming that i'm advocating for upgrading
> optionally-blockable content by default.  I'm not.
>
> I'm advocating upgrading blockable content by default, and leaving
> optionally-blockable content to be dealt with separately.
>

Ok. If that's the case, I'd suggest that we're going to need some form of
opt-in for upgrading optionally-blockable content.

I think that means that there's no long-term risk to shipping the opt-in
version of the directive soon, and in parallel working on ways to improve
our default behaviors. If we get to a place where blockable content is
transparently upgraded, the directive will still be useful to signal
upgrades for optionally-blockable content (which is a longer-term battle,
to be sure).


> > Glad we agree on that. I believe the proposal I've made minimizes
> > cruft by limiting the signals to specific scenarios that we want to
> > drive down. The claim here, I suppose, is that the
> > `upgrade-insecure-requests` signal is itself cruft? My suspicion is
> > that we won't be able to get rid of optionally blockable mixed content
> > via automagical upgrade; opting-in via the directive seems like the
> > right way to approach it, which means that the directive will still
> > have use for years to come (unfortunately).
>
> Maybe you're saying we need two signals, one for optionally-blockable
> and one for blockable content?
>

That's an option. If we decide we need that (or the origin whitelist
concept proposed separately), then I think the syntax is fairly extensible.
That is, tomorrow's `upgrade-insecure-content` could be interpreted as next
year's `upgrade-insecure-content * 'blockable' 'optionally-blockable'`.

I don't think we need to lock ourselves into that syntax right now, though,
without solid feedback from developers that they actually need that
complexity. Starting that feedback loop is my primary goal at the moment.


> But the subresources might only be to other origin servers, not to the
> same-origin (e.g. because the admin was good and fixed all your own
> internal links).  In this case, the only HSTS header you'll see will be
> from the other traffic.
>

I'm assuming that sysadmins capable of fixing links themselves aren't going
to be using this header. The use case that I thought you and Peter were
concerned about was a totally automated LetsEncrypt Apache module (or
similar). Is that not accurate?

I guess I'd consider the "fixed internal subresources, but forgot about
external subresources" to be an edge case that I'm happy to defer until
later, both because it seems unlikely in the first place, and, if it
occurs, it seems transitional. :)

sure, but some proposals block active network attackers from MitMing
> *any* insecure connection after a single secure connection has gone
> through.  The proposal to only send HSTS conditionally fails that test.
>

Is there a relevant difference between the protection against MitM based on
a _single_ secure connection, vs _multiple_ secure connections? That is, if
I don't send HSTS on the response to `https://example.com/`, but do send it
in response to the upgraded request to `http://example.com/logo.png`
generated when rendering that page, have I lost anything? It doesn't seem
like I have.

If no such request is generated (e.g. because I've already upgraded all my
links), then why do I need to send HSTS conditionally?


> The proposal under discussion ends up encouraging setting HSTS on a
> per-user-agent basis, which breaks both of these properties.
>

Ok. What I read from this is that you care significantly more about the
HSTS preload list than the per-request header. Is that accurate?

Assume for the moment that you didn't have any more arguments about the
properties I asserted above, and that per-user-agent HSTS worked exactly as
I'm claiming. `example.com` wouldn't have any problem submitting themselves
to Chromium's preload list, as that's tied to a browser vendor that
supports upgrading.

Firefox and IE pull from this list, which might give `example.com` pause.
But those are evergreen browsers! If `upgrade-insecure-requests` actually
does the things I think it does, and is useful enough for Mozilla and
Microsoft to support it in the future, they can pull it in once they
support upgrading.

Instead of putting together a new header, we would have a flag in the
preload list. That is, hstspreload.appspot.com could look for
`Strict-Transport-Security: max-age=10886400; includeSubDomains;
preload-if-upgrade` or something similarly strawmanny. Chromium would
accept it, Firefox and IE would filter it out of their preload list until
such time as they support upgrading, and everyone's happy.


> I appreciate that, and share these goals! i'd also like to see something
> that we can roll out; hopefully we can hit on a way that will solve most
> issues while leaving deployment relatively easy and avoiding permanent
> protocol cruft.


The sticking point seems to be purely HSTS at this point. I'd suggest that
conditionally sending the header is a reasonable first step, working on a
smarter preload list is a reasonable second step, and that both those steps
will take long enough that we should have some real developer feedback to
work with by the time they're finished. :)

-mike