[webappsec] Disambiguating some subresource integrity use-cases

I mentioned on the call that I thought the last use case example in the SRI
draft mixed some concerns.

The current text states:


   -

   An author wishes to load a resource over an insecure channel for
   performance reasons, but fall back to a secure channel if the
   insecurely-loaded resource is manipulated. She can do this by
adding integrity
   metadata<http://w3c.github.io/webappsec/specs/subresourceintegrity/#dfn-integrity-metadata>and
   a non-canonical
source<http://w3c.github.io/webappsec/specs/subresourceintegrity/#the-noncanonical-src-attribute>
to
   the script element:

   <script src="https://rockin-resources.com/script.js"
           noncanonical-src="http://insecurity-is-inherent.net/script.js"
           integrity="ni:///sha-256;asijfiqu4t12...woeji3W?ct=application/javascript"></script>





I think that fallback/noncanonical has two purposes.

1) Fallback is a way to deal with proxies that transform or modify content,
including proxies trusted by the client to modify data in a TLS connection.
 Whether we think such is legitimate or not, they exist and are somewhat
ubiquitous.  And we should not expect or encourage them to get smart enough
to strip integrity metadata along the way.

The idea of the fallback mechanism here is to specify two ways of
retrieving the content, one of which should *not* require the integrity
check to succeed.

So the user's browser downloads the library controversial.js from "
cdn.example.com".  The administratively trusted proxy at their workplace
modifies it on the way, so it fails the integrity check.  The user's
browser has no way to know, however, whether that change actually
originated at the trusted proxy, or whether the CDN was subverted.  If we
just fail here, we've excluded a large enough portion of our audience that
most sites won't deploy SRI tagging.  But if we give an option to fall back
to a canonical resource that's trusted solely by existing HTTPS mechanisms,
from "www.example.com", the proxy may make the same modification, but we
trust that if all TLS mechanisms succeeded we can let execution proceed.

2) Fallback for mixed-content is similar, but we assume a higher
probability that there are MITM in the plaintext transport.

I think we *need* to support use case 1, even if we don't support 2.

I think this gives us a choice of syntax:

If we only want to support 1, we probably want the attributes:

  src="https://cdn.example.com"  fallback-src="https://www.example.com"

This preserves the behavior of trying the CDN first, and falling back, with
legacy user agents only using the CDN source.

Use case 2 suggests:

  src="https://www.example.com"  noncanonical-src="http://cdn.example.com"

This preserves the no-mixed-content rules for legacy user agents that don't
know about noncanonical-src, but such UAs won't use the CDN version
preferentially.  An SRI-aware UA will try noncanonical first (desired
behavior) and fall back to the (implicitly canonical) src only on an
integrity failure.

I suppose we could have both "fallback-src" and "noncanonical-src"
attributes.  If we really want to accommodate both uses with only one new
attribute, I think "noncanonical-src" is preferrable to "fallback-src", but
it does have some undesired side-effects while legacy UAs still represent
the major share of clients.

At any rate, I think the motivation behind use-case 1 should make it
explicitly into the spec, since these kinds of proxies are going to be a
serious adoption barrier otherwise, as AGL has pointed out.

Thoughts?

-Brad