W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: [SRI] Comments on Subresource Integrity spec

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sun, 17 May 2015 00:51:27 -0700
Message-ID: <CAPfop_11xoErFzTx7CWWPAd5cpyFSRc2pM_azxfhHB2unO7B4w@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: Gervase Markham <gerv@mozilla.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
>
>
>> "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
> :-)
>

One thing I worry about is that the MUST wording might limit UAs---if a UA
wants to deprecate a hash function in one corner of its implementation, the
current wording might force its hand for SRI (and thus affect the ability
to deprecate an old hash function in another corner).

Additionally, deprecation is an art and a long game. For example, UAs might
actually go out and block known broken hashes to make sure the world moves
on to better hashes or it may decide to only warn and then start blocking a
year later. Or do something more weird involving the set of permissions
granted to the script etc.

This sort of stuff requires measurements and trade-offs and I don't think
is something the spec should get into. How about this wording instead?

"User agents MAY deprecate support (by blocking loads) for integrity
validation using hash functions deemed insecure. Web application authors
SHOULD update integrity metadata to remove use of insecure hash functions."

@gerv @joel I feel like this might handle both of your concerns. WDYT?

cheers
Dev


>
>
>>
>> Gerv
>>
>
Received on Sunday, 17 May 2015 07:52:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC