Re: [SRI] Comments on Subresource Integrity spec

On Wed, May 13, 2015 at 1:07 AM Gervase Markham <gerv@mozilla.org> wrote:

> 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."
>
I think, at this point, we need input from others, since I still disagree
:-)

>
> Gerv
>