Re: Comments on last call

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