Re: Comments on last call

On 05/05/2014 09:54 PM, Salz, Rich wrote:
>
> ØI suspect we're further getting to a point where we won't be able to 
> agree / take the feedback meaningfully, as it seems you fundamentally 
> disagree on what we're trying to accomplish.
>
> No, I don’t fundamentally disagree with your goals, I just want to see 
> a some of your algorithms not supported or otherwise made into 
> second-class citizens.  It’d be nice to hear from other WG members.
>

Rich,

I think Ryan has explained that the WebCrypto API, after much argument 
between the Working Group, decided that it would be best to have a 
general-purpose API that exposed many common primitives, even if a few 
of them have known problems. I agree, as Ryan explained, that a 
read-only interface seems unlikely. Note that we have not ignored 
Kenny's argument but have extensively discussed and some clarifications 
have been proposed [1].  Can you live with Ryan's answer?

In particular, there's also been feedback from others that certain 
algorithms should be "second-class citizens". That being said, even 
those that take that position seem to agree that it really not the API's 
place to detail on an algorithm per algorithm basis known security 
flaws. I think that would be a great job for IRTF, and if they made such 
a document I'm sure we'd reference it - it would be useful for a much 
larger class of applications than WebCrypto. However, given that such a 
document does not exist and if you can't live with certain algorithms 
being listed as "recommended" - is the problem really the term 
*recommended*?

I do note in [1] that maybe "we should add some sentences to clarify the 
difference between "registered" (i.e. wellformed and implemented) and 
"recommended" (i.e. recommended for new protocols). We're still pretty 
vague on "recommended" algorithms."

Namely, is the problem really that "RSASSA-PKCS1-v1_5 using SHA-1" and 
"AES-CBC" are listed as "recommended" in this Section [2]?

Two other notes:

1) Note that the WebCrypto document will be immutable unless the Working 
Group is rechartered (like WebApps), which earlier seemed unlikely but 
now seems more likely. Nonetheless, once a document becomes 
Recommendation we cannot "edit" it per se, but instead produce a version 
1.1 and 2.0, so there is good reason not to put per-algorithm security 
concerns that may be added to or change over time in the document.

2) A cross-browser test-suite will be produced by the Working Group that 
should tell developers what algorithms are implemented across browsers. 
We also hope that a "higher-level" algorithm that is safer to build new 
protocols with and for developers is implemented *on top of* Web Crypto. 
In fact, we'd love to see one happen, just no-one has put the work in to 
make a draft spec for it. If so, the WG would definitely consider it in 
addition to Web Crypto. If one does not get built, we can only hope that 
developers will start making them ASAP after WebCrypto exists in 
browsers. We could also put security considerations on a more detailed 
level in the test-suite, and change that document over time as a "living 
document" during the life of the WG.


    cheers,
       harry

[1] http://lists.w3.org/Archives/Public/public-webcrypto/2014Apr/0005.html
[2] http://www.w3.org/TR/WebCryptoAPI/#recommended-algorithms



> -- 
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge, MA
>
> IM: rsalz@jabber.me <mailto:rsalz@jabber.me>; Twitter: RichSalz
>