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

From: Harry Halpin <[email-masked]>
Date: Sun, 01 Nov 2015 18:59:28 -0500

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

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

---

From: Watson Ladd <[email-masked]>
Date: Sun, 1 Nov 2015 19:34:46 -0500

> 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.

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

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

---

From: Taylor R Campbell <[email-masked]>
Date: Mon, 2 Nov 2015 14:30:53 +0000

Date: Sun, 01 Nov 2015 18:59:28 -0500
   From: Harry Halpin <[email-masked]>

   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.

First impression, looking at Table 1: If I were J. Random Web
Developer, I wouldn't have the foggiest idea what most of the ETLA
soup there means.  I know -- as J. Random Web Developer -- that I want
RSA and AES and MD5, because I grew up hearing about them -- but what
are RSAES-PKCS1-v1_5 and RSA-OAEP and RSASSA-PKCS1-v1_5 and RSA-PSS,
and why isn't MD5 listed, and how do I just send a message from one
agent to another agent who have known-good public information about
one another?

Users of crypto need to know what security properties the crypto gives
them and what their responsibilities are for using it.  What's in this
document isn't guidelines for developers -- it's citations for an
audience of cryptographers (if that).

If you want guidelines for developers, it would be much more helpful
to organize the algorithms by protocol, e.g. public-key authenticated
encryption, giving for each protocol what its threat model and user
responsibilities are, and giving for each algorithm its conjectured
security level and any additional caveats.

It is common practice, but calling AES-CTR and AES-GCM both `modes' of
AES is terribly confusing for non-cryptographers -- one of them is a
mere (unauthenticated) encryption function; the other is an
authenticated encryption function.  NaCl sensibly distinguishes them
by calling them, e.g., crypto_stream_xor_aes128ctr and
crypto_secretbox_aes128gcm, not by calling them `modes' of AES.

Some of the entries in the table are individual algorithms with fixed
parameters and specific security properties, such as SHA-256.  But
some are large families, such as `RSA-PSS' and `ECDH', with tremendous
variance in quantitative and qualitative security properties across
the family.

Mixing categories like this in a single table is bound to cause
confusion -- and leaving it up to developers to pick parameters like
group modulus size for finite-field DH, let alone curve for
elliptic-curve DH, is just asking for trouble.

Implementations of RSA, finite-field DH, elliptic-curve DH over all
but a few select curves, and AES, are all historically riddled with
timing side channels.  It is more important for application developers
to know about side channels than to know about the details of
theoretical security reductions.

If you are going to emphasize theoretical security reductions
(`security proofs'), then at the very least you should identify what
the security of a construction reduces to.

For example, RSASSA-PKCS1-v1_5 and RSA-PSS rely on collision
resistance of the hash function, which MD5 flunked; Ed25519 relies
only on target collision resistance, which to my knowledge nobody has
broken for MD5 nor even shown progress toward.  Reliance on collision
resistance of the hash function led to certificate forgery in the wild
by nation-state actors with MD5.

Part of identifying security levels is qualitative properties of the
best attacks:

- The best attack on a single ECDH or FFDH function involves a single
large precomputation to solve ECDLP or FFDLP in that group -- and then
the attacker can quickly decrypt every past recorded key exchange.
For RFC 2409 Group 2, namely (Z/pZ)^* over a 1024-bit prime p, that
precomputation is feasible today; for Curve25519, it's not.

- The best attack on AES-128 is on multiple targets simultaneously,
with no precomputation -- 2^n time to attack any of 2^k targets in
parallel can give success probability ~2^-(128 - n - k), typically
much larger than what one might naively expect, ~2^-(128 - n).  Hence
a common choice to use AES-256 instead of AES-128 for a 128-bit
aggregate security level.

- For many applications, long-term confidentiality matters more than
long-term authenticity: signing keys may expire in a year but the NSA
keeps all your ciphertext for eternity to try decrypting it later if
they ever manage to build a quantum computer.  So for confidentiality
properties, the post-quantum security level is worth considering now.

These qualitative properties needn't necessarily be given in detail as
guidelines to developers, but they are relevant to what you advertise
as the security level of, e.g., AES-128, or RSA-OAEP over a 2048-bit
modulus.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Nov 2015 16:17:05 +0100

> http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-01.html

1) Why is AES-CBC, AES-CFB, AES-CTR marked YES in the "OK Future"
column?  I believe there is general agreement that you should be using
AEAD ciphers and that non-AEAD ciphers are too fragile for any use by
non-crypto people.

2) Why are you promoting the SP 800-56A CONCAT construct?  Use HKDF.

3) HKDF is not a password-based key derivation function and shouldn't be
used for that purpose.

4) PBKDF2 is a decent password-based kdf.  If you want to deprecate
PBKDF2, point to Scrypt or Argon2, not HKDF.

5) You may want to remind people that MD5 is broken, so that nobody
thinks that it is okay to use it because your document does not mention
it.

/Simon