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

Re: [SRI] unsupported hashes and invalid metadata

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sat, 7 Feb 2015 23:00:53 -0800
Message-ID: <CAPfop_29esxK0S59Hqk-PtAyW2+PbHKZCfY39Vpbis_rGewzsg@mail.gmail.com>
To: Francois Marier <francois@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Circling back to this; what do ya'll think should we go with here?

I still believe we should fail open and then go with the SSL style
deprecation Brad suggested.

If a browser knows that a hash is insecure, it can start showing
warning before failing closed. We don't need to spec this.

If a browser doesn't know of a hash, it should just ignore it (maybe
with a warning).

This makes sense to me in that the presence of a known bad hash is a
signal for a UA to make some security decisions; but not knowing an
algorithm might just be that the UA is old enough and doesn't know any
good, safe algorithms.


On 3 January 2015 at 12:46, Devdatta Akhawe <dev.akhawe@gmail.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 think you're suggesting we fail open (for a time anyways) in the first
>> case by keeping a list of known-but-no-longer-trusted hash algorithms. I
>> can draft a pull request for this.
> Do we really need to spec the first case? I think we should leave it
> to UAs to decide what is best for their users.
> cheers
> Dev
Received on Sunday, 8 February 2015 07:01:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC