Re: [Cfrg] WebCrypto Security Guidelines into IRTF Informational Draft?

On Sun, Nov 1, 2015 at 6:59 PM, Harry Halpin <hhalpin@w3.org> wrote:
> CFRG,
>
> Note we did a update taking into account the last round of feedback of the CFRG, and we'd like to ask CFRG if they are any objections to moving this forward. I can file and Internet Draft tomorrow if there are no objections to moving it forward. Input from end-users of the WebCrypto W3C draft said a security guideline document would help them, so we'd like to have this resource available and myself and INRIA can maintain it.  Developers will mostly look at the "Yes/No" table for future use.
>
> The new draft is here:
>
> http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-01.html

I think this is a necessary idea, but I have several substantive comments:

This document discusses nonce reuse issues with AES-CTR but not with
AES-GCM. This is a recipe for disaster, as readers will not realize
that the same warning needs to be applied to both.

The above discusses CCA security. Is this actually useful to a
developer who doesn't know anything about cryptography, the intended
audience for this document?

HKDF should not be used with passwords! As it stands the above
document recommends it over PBKDF2.

There are no key size recommendations. RSA 512 is perfectly fine
according to this document.

"Note that draft, while attempting to gather consensus of the
cryptographic literature, may not be complete and there may be
disagreement". What, you expect attacks to depend on Mochizuki's proof
of ABC conjecture, or Arthur finishing the proofs in chapter 9 of his
book? No, there is really no disagreement  for these algorithms about
what the best attacks are and how long they take.

Many of the citations are just wrong. The claim of security proofs of
ECDH links to a paper about hard-core predicates, which, while
theoretically important, aren't what protocols rely on. This
misunderstanding of how security proofs work extends to ECDSA. While a
Pointcheval-Stern result doesn't exist, I doubt anyone believes a
forger exists with time-space complexity substantially faster than
solving discrete logarithms. All security proofs are dependent on
assumptions like one-way function (at weakest) or strong RSA (medium)
or sometimes ridiculous assumptions like q-XSIGDH (I hope that isn't a
real assumption, but it might be!). The statements about proofs
murders these details, and the result is just wrong.

It remains unclear to me how this document helps developers. If they
make applications which need to comply with bad crypto in an old
protocol, they are stuck. If they don't have an existing model, they
are making new crypto and really, really should call someone before
they go on. So what's left, and what do they need to know?

I hope that these points can be corrected as this document progresses.

>
> The main changes, based on CFRG feedback, was to change the 'No' to future use for ECDSA to 'Yes.' We've updated the description of applying MACs to anything not AES-GCM, and added a reference to the Weak DH attack, as well as clarified the 'nonce' terminology.
>
> We have *not* yet added CFRG curve recommendations, although we will once browser vendors decide to expose them to WebCrypto. We think a paragraph that then explains the nuances (side channels, etc.) of the CFRG's discussion re elliptic curve choice would be useful.
>
> I am not at IETF but Wendy Seltzer is and she can possibly field questions if she is in CFRG about W3C process, although not the specifics of the document.
>
> Again, we'd like to maintain this document, so we welcome feedback.
>
> Although not formally tied to any particulars, we'd like for the W3C WebCrypto spec to reference this document informationally before it goes to Recommendation status at the end of the year.
>
>  cheers,
>             harry
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.