- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 30 Dec 2014 18:12:57 +0000
- To: Francois Marier <francois@mozilla.com>, public-webappsec@w3.org
- Message-ID: <CAEeYn8jEDStjpbT9ZCRPQEPGsgyqz8nsekGp3C4LDNpOf2WSfQ@mail.gmail.com>
> > > > **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