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

[Taylor R Campbell <[e-mail]>]

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

   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.