- From: <bugzilla@jessica.w3.org>
- Date: Thu, 08 May 2014 21:33:28 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607 --- Comment #4 from Ryan Sleevi <sleevi@google.com> --- Bug 25431 is about an entirely different attack than simply "warning" - it's about the implementation making it impossible to use RSA-ES securely (which it can be, with careful consideration - as in the case of a "good" TLS impl) Bug 18925 is a re-statement of the need not to introduce issues like Bug 25431, which was introduced, unfortunately, with the addition of error codes and the abstracted idea of wrap/unwrap. Bug 25569 is about adding new algorithms entirely, particularly ensuring that they are part of the "Recommended for implementors" section. Your proposal does not change this need. Bug 23499 is a dupe of this (or more aptly, this is a dupe of it), for which was addressed on the list. This is different wording, but conceptually the same. Further, the guidance proposed here isn't really sufficient. I disagree with your analysis of CTR, CBC, and CFB. While yes, it's true that in and of themselves they have risks, they are not 'doomed' (RSAES is far more likely to be considered doomed - as would be MD5 and RC4). That is, you can add authentication and construct safe uses - as draft-mcgrew shows. It's important for you to realize that listing all of the failures in the algorithms is, implicitly, recommending a set of 'safe' algorithms (eg: those without risks). That is, the omission of attacks for ECDH (of which there exist timing attacks) or ECDSA (which, of course, is absolutely and completely fatal if the nonce isn't random, and hence why many uses are now taking to incorporating H(M) in the nonce when computing signatures for M) implies they're inherently safe, but they're not. If the spec were to instead say "These are the algorithms new [web developers] are recommended to use when implementing new protocols", it's quite obvious to see there's a fundamental problem - you shouldn't be implementing new protocols WITHOUT understanding all of these caveats. I have serious doubts that listing the attacks will save anyone, ever, from making a cryptographic mistake. They fall into simple use cases: 1) Implementing an existing protocol - Regardless of whatever normative advice in this spec, they're going to follow that protocol's spec. Maybe they'll read the BIS and Errata, maybe they won't. Here, all that matters is what the market does, not whatever a spec says 2) Implementing a new (standard) protocol - Either the protocol set out good advice or it didn't. JOSE is an example of, arguably, good advice (notwithstanding Microsoft's request to add RS1 as valid for JWS in Bug 25570) 3) Implementing a new (custom) protocol - Look, here, you're doomed if you don't understand all these attacks already. Even if you say "use AES-GCM", you're still going to have issues with key selection, derivation, etc. Any advice against is, implicitly, advice for. And "advice for" is something this WG has explicitly decided against. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 8 May 2014 21:33:29 UTC