[Integrity] Comments/Questions on Subresource Integrity spec

Hi,

I was on leave for a few months and away from the webappsec working 
group.  I am back now and very pleased to see that we have a FPWD of 
Subresource Integrity!  The spec looks like it's in good shape. I've 
missed some of the discussions, so forgive me if some of this has 
already been addressed.  I have the following comments and questions on 
the spec.

*1.1 - Goals*
"2. The verification mechanism should extend to all resource types that 
a page may fetch in the course of its execution and rendering. Active 
content (scripts, style, |iframe| contents, etc) are, of course, 
critical, but inactive content such as images and fonts will also be 
covered."
Here it says that fonts are covered, but I don't see anything about 
fonts in the spec.

"5. (potentially) Relax mixed-content warnings for resources whose 
integrity is verified. If the integrity metadata for a resource is 
delivered over a secure channel, the user agent might choose to allow 
loading the resource over an insecure channel."
We could allow mixed active content loads that pass an integrity check 
(instead of blocking them) and use the UI for mixed display content in 
these cases (instead of showing the lock).

*2.1 - Key Concepts and Terminology*
"The SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of 
cryptographic hash functions defined..."
Looks like SHA-384 isn't used anywhere in the spec.
*
**3.3.2 - Is resource eligible for integrity validation*
"In order to mitigate an attacker's ability to read data cross-origin by 
brute-forcing values via integrity checks, resources are only eligible 
for such checks if they are same-origin, publicly cachable, or are the 
result of explicit access granted to the loading origin via CORS. [CORS]"
Was there a discussion that these restrictions came out of?  I 
understand the need for them but am worried if about overly constraining 
the feature.  Are there common instances where a resource may not be 
publicly cachable but wouldn't have any private data or leak information?

*3.5 Verification of HTML document subresources*
"...a new |integrity| attribute is added to the list of content 
attributes for the |a|, |audio|, |embed|, |iframe|, |link|, |object|, 
|script|, |source|, |track|, and |video| elements."
images are missing from this list.

*3.5.2 - Noncanonical source*
Does the noncanonical (fallback) source have to match the integrity check?
* If it does have to match the integrity check - what if it is over 
HTTPS?  Does that make a difference or does it have to match either 
way?  Is there a case where we are in block mode (not report mode) and 
we don't have to match the integrity check?  Consider this case - a 
website includes third party javascript over HTTP instead of HTTPS for 
performance reasons.  The third party javascript library is updated and 
the HTTP version of the file hence fails the integrity check.  The site 
includes the HTTPS version as a fallback, but it to will fail the 
integrity check.  If the integrity check wasn't required for an HTTPS 
fallback, then the site would still function and the administrator would 
be alerted of the issue in the report.

* If it does not have to match the integrity check - what would be the 
point of having a noncanonical source over HTTP?  Should we require it 
to be HTTPS?  If the original HTTP source doesn't match the integrity 
check, why fall back to another HTTP source?  If there is a MITM attack, 
the MITM can alter the fallback as well.  A case where an HTTP 
noncanonical source might be helpful is if there is a third-party server 
compromise that caused the mismatch and the noncanonical source is an 
HTTP link with the same origin as the top level page.

*3.5.4 - Handling integrity violations*
Why have separate block and fallback modes?  If the site didn't want to 
fallback, they wouldn't have included a noncanonical source.

*3.5.5.1 - The /a/ element*
"If subject has an integrity attribute whose value is not the empty 
string, then:..."
What does subject refer to here?

"If response's integrity state is corrupt and the document's integrity 
policy is block, the user agent MUST report a violation, and MUST abort 
the download."
This section doesn't say what to do if the document's integrity policy 
is report (while most other sections do).  Perhaps you can add a line 
here stating something like -
'If response's integrity state is corrupt and the document's integrity 
policy is report, the user agent MUST report a violation, and can 
continue with the download.'

And finally a general question - what happens when third party resource 
is only available over HTTP and it changes?  If a website requires an 
integrity check for that resource, it will fail until the website views 
their reports, reviews the new code/resource, and updates the hash.  The 
resource may have been necessary for the site to function.  I'm worried 
that web administrators will be too scared to use integrity checks for 
third parties out of fear that the resource will slightly change and 
break their site.  Is there anything we can do to mitigate this risk and 
increase adoption?

Thanks!

~Tanvi