- From: Joshua Cranmer 🐧 <Pidgeot18@gmail.com>
- Date: Mon, 05 May 2014 12:17:30 -0500
- To: public-webcrypto-comments@w3.org
- Message-id: <5367C7AA.9030205@gmail.com>
On 5/1/2014 3:24 PM, Salz, Rich wrote: > > I understand the desire to leave guidance for a separate document. > There are many rationalizations for that, from “mechanism not policy” > through to the claim that a separate document makes us more flexible > to policy changes when new attacks are found. This may be true, but > when the W3C and IETF official consider that the Internet is under > attack from pervasive monitoring, you are shirking your > responsibilities if you provide millions of Javascript programmers > API’s that will create cryptographically weak objects. As a gedanken > experiment, suppose a member of the working group wanted inclusion of > the classic Usenet “rot-13” cipher. By what rationale could, or would, > that be exluded from this document? Similarly, why isn’t triple-DES > specified? > Actually, I'm concerned that DSA is missing because I have a use case for WebCrypto that gives me DSA as the only allowed public key type. (OTR, if you're wondering: <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html>). > At a minimum, there should be an open review for attacks against the > defined mechanisms. Those which have well-known attacks, and those > which have been superceded by better mechanisms, should either be > withdrawn, or have a “read-only” interface available. An argument can > be made that interoperability with a deployed base requires the > ability to read such items; the case for being able to **create** them > is a much weaker one, and should be available, if at all, only under > duress. > If you'd read the archives, you'd have realized that the working group here did take this concern seriously. Building secure applications is more than just choosing secure algorithms, as even the history of TLS will no doubt indicate. The conclusion was made to first advance a low-level cryptographic primitive specification (so as to avoid people writing insecure AES implementations in JS, say) and then to build a "high-level" specification that provides much stronger cryptographic guarantees. The current draft is not intended for idiot programmers who think "I'll just wrap it in a secure box"--it's intended for people who need to implement already-studied and security-reviewed protocols. In a similar vein, arguing that "weak" primitives only need partial support is a great disservice. Suppose I'm building an email application that uses S/MIME or PGP to encrypt email contents. Am I supposed to tell my users "Sorry, I can't do the encryption you requested because your browser won't let me encrypt to a weak public key?" To an end-user, that is a bug, not a feature. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist
Received on Monday, 5 May 2014 17:18:23 UTC