Re: [SRI] unsupported hashes and invalid metadata

On 28/12/14 17:49, Devdatta Akhawe wrote:
> I am not sure this is convincing enough, but I definitely want to
> think about this a bit and would be curious how other specs,
> particularly security specs, handle this. While Postel's law might
> suggest failing open, there is obviously some tension with security.
> But, to actually achieve adoption (and thus security) maybe fail-open
> is necessary.

Another scenario (from the point of view of the site owner) came to my
mind while reading this:

"Imagine a developer puts together a website on contract and decides to
make use of SRI with a state-of-the-art SHA-512 hash in order to protect
their customer's website against a compromise at code.jquery.com.

5 years later, the developer is long gone but the site is still going.
However, SHA-512 is no longer considered secure and browsers no longer
support it for SRI."

**Failing closed** in this case means that we suddenly break a site that
has been working for a long time. As far as the client is concerned, it
was a mistake on the part of their contract developer to use SRI.

**Failing open** means that the site was working fine (and benefiting
from the integrity protections of SRI) for a while but now it's
operating in "legacy mode" whereas it still works but modern browsers
make no integrity guarantees [1] about the code that comes from
code.jquery.com.

Francois

[1] If SHA-512 ever were to be completely compromised, it wouldn't
matter whether or not we check the hash. Regardless of what browsers do,
the only way to guarantee the integrity of a sub-resource once a hash
algorithm is compromised is to switch to a new hash algorithm.

Received on Monday, 29 December 2014 23:48:12 UTC