Re: [webappsec] Disambiguating some subresource integrity use-cases

I am not sure we should design for use-case 2. It is not clear that browser
vendors even plan to take away mixed content warnings due to HTTP resources
loaded with integrity metadata. E.g., see Ryan's comments about the SRI
spec.

Thanks
Dev






On 17 January 2014 12:08, Brad Hill <hillbrad@gmail.com> wrote:

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