Re: [SRI] Comments on Subresource Integrity spec

On 12/05/15 04:16, Joel Weinberger wrote:
> I still disagree. We could also support ROT13, which would stop some
> number of attackers as well, but it wouldn't really fit a definition of
> "secure." It's important to keep a clear set of security guarantees of
> what an integrity check gets you. 

Perhaps you misunderstand what I'm asking for. I'm not suggesting the
spec retain support for dodgy hash functions. I'm saying the spec should
not mandate (or even suggest) that implementations should stop checking
hashes from those functions even after they've been removed from the
spec. Given that ignoring it means loading the resource anyway, there is
absolutely no downside to checking it. One may also want to throw a
console warning, but one should check it nevertheless.

> Additionally, the discretion of what hash functions are used is still up
> to the user agent. 

Not so. Section 3.2.1:

"When a hash function is determined to be insecure, user agents MUST
deprecate and eventually remove support for integrity validation using
that hash function."

Are you saying that "determined" in this sentence is not "determined by
the spec" or "determined by community consensus", but "determined by the
author(s) of each individual UA"?

The sentence above is the one I take issue with. I think it should say:

"When a hash function is determined to be insecure, user agents MUST
deprecate support for integrity validation using that hash function, but
MAY continue to check hashes which use it."

Gerv

Received on Tuesday, 12 May 2015 15:07:39 UTC