W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: [SRI] unsupported hashes and invalid metadata

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 30 Dec 2014 18:12:57 +0000
Message-ID: <CAEeYn8jEDStjpbT9ZCRPQEPGsgyqz8nsekGp3C4LDNpOf2WSfQ@mail.gmail.com>
To: Francois Marier <francois@mozilla.com>, public-webappsec@w3.org
>
>
>
> **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.
>
>
The client may think so, but they would be mistaken. (The same client might
also think it was a mistake to use HTTPS if the site stops working when
they don't renew their certificate in 18 months and would be wrong there,
as well.)  The point of SRI is to enforce a security guarantee, and it is
the nature of all cryptography thus far developed that those guarantees to
not have an unlimited life.  We decay the experience and / or break things
for expired keys or out of date algorithms all the time, and there is an
implicit understanding that anything that requires security will also
require maintenance. (even DJB's code!)

I also think there is a third way to handle deprecated algorithms - the way
we handle them for SSL today - fail open and show a warning to encourage
operators to perform necessary maintenance, then, after a reasonable time,
fail closed.

We have some reasonable amount of experience and history with secure
hashing algorithms and how they fail to expect that a complete break in a
very short period of time is quite unlikely, absent something like a
quantum computing breakthrough with much broader implications.  So the best
guess we can make is that SRI will still be fairly safe to fail open on a
deprecated algorithm for some period of time after it is considered
"broken" by the security and cryptography community and we can provide
incentives for operators to update during that window.

-Brad
Received on Tuesday, 30 December 2014 18:13:25 UTC

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