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

Hey Daniel! Thanks for the proposal!

It probably won't surprise you too much that I think the upgrade draft has
some advantages over HSTS2. I'll walk through some of the line-by-line
below, but at a high level, I think it's worthwhile to separate the
concepts of a resource-representation-specific request to upgrade insecure
subresources on the one hand, and a host-level opt-in to transport security
on the other.

UPGRADE is, in my mind, little more than a catalyst for migration from HTTP
to HTTPS. It removes one barrier (mixed content in old pages) that we've
heard is practically insurmountable for a subset of important sites, and it
attempts to do so in a fairly targeted way. Given that target audience, I
think that it's somewhat counterproductive to tie the upgrade mechanism to
HSTS. The CSP directive I've proposed is scoped to a specific resource
representation, and can be rolled out in a very granular fashion, which
allows authors to gradually gain confidence in both the mechanism and their
own TLS configuration, by (for example) upgrading low-traffic pages first,
measuring the response, and then moving to higher-traffic pages.

Host-level mechanisms don't allow this granularity, and I think that would
inhibit the adoption of the upgrade mechanism. That would be unfortunate,
since rapid adoption is the _only_ advantage of UPGRADE over just asking
authors to fix their sites to work in today's browsers.

With that in mind, let's look at the details:

On Sun, Mar 8, 2015 at 10:51 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

>  * avoid having to keep legacy headers around forever
>

1. Which legacy header does UPGRADE leave around forever? As much as I'd
like CSP to be obsoleted, I don't see that happening in the near term.

2. We'll still have to support today's non-upgrading HSTS forever, right?


>  * origin operators can set HSTS headers unconditionally
>

Assuming they're ready for supporting browsers to use TLS and only TLS for
a host, they could. I worry that that is a commitment they wouldn't be
willing to make.


>  * HSTS2 header is shorter (fewer bytes is a minor efficiency
>    optimization)
>

I like fewer bytes! Maybe we should rename `Content-Security-Policy` to
`CSP` in the next iteration. Two characters shorter still!

That said, I also like self-explanatory text. And HTTP/2's magical header
compression dust should reduce the impact of header bloat, right? :)


>  * large number of broken sites can get fixed without the operator
>    learning and deploying CSP
>

What's to learn? I think folks would be quite capable of copy/pasting
`Content-Security-Policy: upgrade-insecure-requests` from the spec without
understanding the nuances of the `child-src` directive. As no other
directives are present, no other behavior is triggered. *shrug* They don't
have to learn the rest if they don't want to.

That said, I'd (selfishly!) claim that if we _did_ happen to inspire some
folks to ask about the header, they'd be well-served by learning more. This
might be a nice way of whetting their appetite for more. "If CSP can solve
this problem for me," they'll say, "maybe it can help me with other things
too! I'll go read that whole specification right now! Thanks, WebAppSec!"

 * navigational upgrade can be handled for subdomains or not at the
>    server operator discretion by choosing whether to set
>    "includeSubdomains" in the HSTS2: header.
>

If we end up running with https://w3c.github.io/webappsec/specs/csp-pinning/,
I hope we'll be able to offer similar capability for CSP-delivered policy.


>  * Client implementations can be simplified because there is no need to
>    decide whether to send Prefer or not.
>

I don't understand this claim. Use case #4 in the other thread seems to
require some sort of signal to the server in order to safely downgrade
legacy user agents. I don't think HSTS2 presents any capabilities that
would avoid that necessity. I believe that's what Peter was referring to in
his response earlier in this thread.

-mike