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

Re: [SRI] unsupported hashes and invalid metadata

From: Brian Smith <brian@briansmith.org>
Date: Sun, 8 Feb 2015 21:38:37 -0800
Message-ID: <CAFewVt5=TYM1s+vm1ie8-Uce=eJb0n2NfK5G-BcUgdP+=qTGaA@mail.gmail.com>
To: Francois Marier <francois@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Francois Marier <francois@mozilla.com> wrote:
> 1. <script integrity="ni:///sha-512;foo"> for a modern browser that no
> longer considers that hash algorithm secure
>
> 2. <script integrity="ni:///sha-1024;foo"> for an older browser that
> doesn't know about this new hash algorithm

I would phrase these differently:

1a. The browser recognizes the algorithm by name, the algorithm is not
considered secure, and the browser still implements the algorithm.

1b. The browser recognizes the algorithm by name, but the algorithm is
not considered secure, and the browser no longer wants to implement
the algorithm.

2. The browser does not recognize the algorithm, and thus it doesn't
implement it.

I suggest that for 1a, a warning be given in the developer console,
but the browser should continue to enforce SRI just like it would for
a secure algorithm.

I suggest that for 1b, a warning be given in the developer console,
and the browser treat it just like SRI isn't being used.

I suggest that for 2, a warning be given in the developer console. By
default the browser should treat the fetch as though the integrity
check failed (fail closed), on the assumption that the unrecognized
name was probably a typo or other developer error. However, there
should be some mechanism for the web page to tell the browser that the
use of some unrecognized digest algorithm names is intentional and
should be treated like case 1b. For example, <meta
name=secure-digest-algorithms content="sha256 sha3-256 sha2-512/256">.

Cheers,
Brian
Received on Monday, 9 February 2015 05:39:08 UTC

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