Subject: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API

From: Harry Halpin <[email-masked]>
Date: Thu, 20 Nov 2014 16:38:13 +0100

Everyone,

As the W3C Web Cryptography API gets ready to move to Candidate
Recommendation, we wanted to address the concerns brought up by Rich
Salz and others for better security guidelines for developers, given
that the API exposes a variety of algorithms. I've taken Graham Steel's
excellent write-up, which is in a large part based on Smart et al.'s
magisterial ENISA report,  and have turned it into a draft CFRG note.

We'd like to see the security guidelines below discussed here, and if
there's no objections after discussion, move this onwards. W3C commits
to maintaining this note as much as possible.

Links to draft:

TXT:
http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.txt
HTML:
http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.html

cheers,
    harry

----

Crypto Forum Research Group                               H. Halpin, Ed.
Internet-Draft                                                   W3C/MIT
Intended status: Informational                                  G. Steel
Expires: May 23, 2016                                  Cryptosense/INRIA
                                                       November 20, 2015

    Security Guidelines for Cryptographic Algorithms in the W3C Web
                            Cryptography API
                draft-irtf-cfrg-webcrypto-algorithms-00

Abstract

   This overview document provides information on the current state of
   algorithms made available by the W3C Web Cryptography API, including
   whether protocols have security proofs or known weaknesses.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 23, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Halpin & Steel            Expires May 23, 2016                  [Page 1]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Document Conventions . . . . . . . . . . . . . . . . . . . . .  5
   4.  Conformance Criteria . . . . . . . . . . . . . . . . . . . . .  5
   5.  Algorithm Review . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  RSAES-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  RSA-OAEP . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3.  RSASSA-PKCS1-v1_5  . . . . . . . . . . . . . . . . . . . .  6
     5.4.  RSA-PSS  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.5.  ECDSA  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.6.  ECDH . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.7.  AES-CBC, AES-CFB, AES-CTR  . . . . . . . . . . . . . . . .  6
     5.8.  AES-GCM  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.9.  AES-CMAC . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.10. AES-KW . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.11. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.12. DH . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.13. SHA1 . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.14. SHA-256, SHA-384, SHA-512  . . . . . . . . . . . . . . . .  9
     5.15. HKDF-CTR . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.16. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.17. CONCAT . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Halpin & Steel            Expires May 23, 2016                  [Page 2]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

1.  Introduction

   Cryptography is a small but important part of security, and choosing
   the right cryptographic algorithm is a small but important part of
   deploying cryptography.  Many developers find it difficult to follow
   the current state of cryptanalytic research regarding particular
   algorithms.  This document gives a concise overview of known
   weaknesses and the state of security proofs in standard developer-
   facing APIs such as the W3C Web Cryptography API [W3CWebCryptoLC].
   This analysis may also be useful in analyzing the properties of
   protocols given in the algorithms used by the IETF JSON Web
   Algorithms [JWA].

   This overview provides no substitute for a detailed analysis of a
   particular protocol: when deploying cryptographic algorithms in Web
   and Internet applications, developers should strictly follow the
   instructions given by the cryptographic protocol and avoid creating
   new protocols.  Developers should also be aware of the intended
   threat models of the cryptographic protocols they are implementing
   and note that some aspects of deploying a protocol in the context of
   an internet application, such as the use of Javascript and the Web,
   may change some of its security properties.  For example, Javascript
   code is always ultimately controlled by the origin, thus making end-
   to-end encryption without a trusted origin of the code impossible.
   Questions about and proposals to improve the Web Security Model
   should be sent to the W3C Web Security Interest Group at
   "[email-masked]"

   In this review, we limit ourselves to peer-reviewed results on the
   algorithms which have been included in the latest public draft of the
   W3C Crypto API [W3CWebCryptoLC].  Where appropriate we also comment
   on the status of the algorithm in other standards.  Note that this
   represents a point-in-time snapshot of the state of the art in
   cryptanalysis and provable security results, which is a complex area
   subject to (sometimes rapid) change.  There is at least one annual
   publication, the ENISA Algorithms, Key Size and Parameters Report,
   whose aim is to track these developments [enisa13].  That document
   discusses a much larger set of algorithms in much greater depth that
   we do here.

   Please discuss this draft on the mailing list "[email-masked]".  Note
   that draft, while attempting to gather consensus of the cryptographic
   literature, may not be complete and there may be disagreement, so
   that readers should view the archives of the CFRG mailing list to be
   aware of debates and ongoing analysis.

Halpin & Steel            Expires May 23, 2016                  [Page 3]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

2.  Overview

   This following table summarizes the results.  The marks for legacy
   and future applications are the same as in the 2013 ENISA report
   [enisa13], except for those algorithms (PBKDF2 and AES-KW) which are
   not covered by the report where the marks represent interpretation of
   the available literature.

   +-------------------+----------+----------+-------------------------+
   |   Algorithm/Mode  |    OK    |    OK    |           Note          |
   |                   |  Legacy  |  Future  |                         |
   +-------------------+----------+----------+-------------------------+
   |  RSAES-PKCS1-v1_5 |    YES   |    NO    |                         |
   |      RSA-OAEP     |    YES   |    YES   |                         |
   | RSASSA-PKCS1-v1_5 |    YES   |    NO    |    No security proof    |
   |      RSA-PSS      |    YES   |    YES   |                         |
   |       ECDSA       |    YES   |    NO    |  Weak provable security |
   |                   |          |          |         results         |
   |        ECDH       |    YES   |    YES   |                         |
   |      AES-CBC      |    YES   |    YES   |    NB not CCA secure    |
   |      AES-CFB      |    YES   |    YES   |    NB not CCA secure    |
   |      AES-CTR      |    YES   |    YES   |    NB not CCA secure    |
   |      AES-GCM      |    YES   |    YES   |                         |
   |      AES-CMAC     |    YES   |    YES   |                         |
   |       AES-KW      |    YES   |    NO    |    No public security   |
   |                   |          |          |          proof          |
   |        HMAC       |    YES   |    YES   |                         |
   |         DH        |    YES   |    YES   |                         |
   |       SHA-1       |    YES   |    NO    |  Known weaknesses (see  |
   |                   |          |          |          text)          |
   |      SHA-256      |    YES   |    YES   |                         |
   |      SHA-384      |    YES   |    YES   |                         |
   |      SHA-512      |    YES   |    YES   |                         |
   |       CONCAT      |    YES   |    YES   |                         |
   |      HKDF-CTR     |    YES   |    YES   |                         |
   |       PBKDF2      |    YES   |    NO    |  Known weaknesses (see  |
   |                   |          |          |          text))         |
   +-------------------+----------+----------+-------------------------+

      The Algorithm/Mode is the title by the W3C Web Cryptography API
    [W3CWebCryptoCR].  Whether or not the protocol is considered secure
     for legacy use or for future protocols is given next, followed by
    notes regarding its security properties (such as security proofs).

                     Table 1: Algorithm Summary Table

Halpin & Steel            Expires May 23, 2016                  [Page 4]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

3.  Document Conventions

4.  Conformance Criteria

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

5.  Algorithm Review

   In this review, we overview the following algorithms listed in the
   table.  They are all currently given in the W3C Web Cryptography API,
   although RSAES-PKCS1-v1_5 (present in an earlier version of the Web
   Cryptography API [W3CWebCryptoLC].) was withdrawn from the W3C Web
   Cryptography API [W3CWebCryptoCR].  This analysis originates in work
   done by Graham Steel [SteelChoice].  If algorithms are added, we will
   attempt to add them to this analysis in due course.

5.1.  RSAES-PKCS1-v1_5

   This encryption scheme has been known to be vulnerable to a chosen
   ciphertext attack (CCA) since 1998 [bleichenbacher98].  The attack
   has recently been improved to require a median of less than 15,000
   chosen ciphertexts on the standard oracle [bardou12padding].
   Instances of the attack in widely-deployed real-world systems
   continue to be found [jager12bleichenbacher].

   Since version 2.0 (September 1998), the RSA PKCS#11 standard contains
   the text: "RSAES-PKCS1-v1_5 is included only for compatibility with
   existing applications, and is not recommended for new applications"
   [PKCS11].

   TLS up to version 1.2. supports RSAES-PKCS1-v1_5, but using specific
   countermeasures that 1) substitute a message with a random value in
   the event of a padding error and 2) require the client to display
   knowledge of the plaintext before proceeding with the protocol.
   These countermeasures are not trivially transposable to other
   applications.  Finally, note also that as of version 1.3, RSAES-
   PKCS1-v1_5 will be dropped from the TLS standard.

   The RSAES-PKCS1-v1_5 scheme was removed from the draft during the
   Last Call review period of the W3C Web Cryptography API.  Despite
   this, it is still to be found in the Trusted Platform Module (TPM)
   standard, PKCS#11, Java JCE/JCA, MS-CAPI all support it.  TPM 1.2 did
   not support it, favouring OAEP (below), but it may be included in TPM
   2.0 (see section 14.2.1, Level 00 Revision 01.07).

Halpin & Steel            Expires May 23, 2016                  [Page 5]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

5.2.  RSA-OAEP

   Has a security proof of preservation of indistinguishability under
   chosen ciphertext attacks (IND-CCA, the standard desirable notion of
   security for an encryption scheme) [fujisaki04OAEP].  Indeed, the
   proof has been formalised in the Coq proof assistant
   [barthe2009POPL].  These proofs assume that a well-known
   implementation pitfall leading to an efficient attack [manger01] is
   avoided.

   Using OAEP implies using a hash function.  A recent report recommends
   using SHA-1 inside OAEP for legacy applications only and using
   SHA-2/3 for future applications [enisa13].

5.3.  RSASSA-PKCS1-v1_5

   There are no publicly known attacks on this scheme.  However, there
   are also no security proofs and no advantages compared to other RSA-
   based schemes such as PSS (below) [enisa13].

   An RSA Laboratories memo by Burt Kaliski, dated February 26 2003,
   states "'While the traditional and widely deployed PKCS#1 v1.5
   signature scheme is still appropriate to use, RSA Laboratories
   encourages a gradual transition to RSA-PSS as new applications are
   developed" [email].

5.4.  RSA-PSS

   Has a security proof due to Bellare and Rogaway [bellare96eurocrypt]
   in the random oracle model.

5.5.  ECDSA

   ECDSA schemes have some provable security results but only in weak
   models [enisa13].  Further it may be possible to maliciously choose
   an elliptic curve for ECDSA despite the standard validation scheme
   [vaudenay03PKC].

5.6.  ECDH

   ECDH has provable security results [boneh01crypto].  Like other plain
   DH modes it offers no authenticity, this must be taken care of
   separately.

5.7.  AES-CBC, AES-CFB, AES-CTR

   There are known cryptanalytic attacks on AES that are not currently
   believed to pose a practical threat [kaminsky10].  The following

Halpin & Steel            Expires May 23, 2016                  [Page 6]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

   results assume that AES is a secure block cipher.

   AES-CBC mode is not CCA secure.  It is secure against chosen
   plaintext attacks (CPA-secure) if the IV is random, but not if the IV
   is a nonce [rogaway11evaluation].

   It does not tolerate a padding oracle [vaudenay02] - indeed, in
   practice, padding oracle attacks are common
   [paterson04padding][mitchell05cbc][rizzo10USENIX] and the padding
   mode suggested in the current draft is exactly that which gives rise
   to most of these attacks.

   AES-CFB is not CCA secure.  It is CPA-secure if the IV is random, but
   not if the IV is a nonce [rogaway11evaluation].

   AES-CTR is not CCA secure.  It is CPA-secure but not CCA-secure
   [rogaway11evaluation].

   For a summary of the properties of these modes and the dangers of
   using ciphers with only CPA-security, the following excerpt from
   Rogaway's review [rogaway11evaluation] is apposite:

   "I am unable to think of any cryptographic design problem where,
   absent major legacy considerations, any of CBC, CFB, or OFB would
   represent the mode of choice.  I regard CTR as easily the "best"
   choice among the set of the confidentiality modes (meaning the set of
   schemes aiming only for message privacy, as classically understood).
   It has unsurpassed performance characteristics and provable-security
   guarantees that are at least as good as any of the "basic four" modes
   with respect to classical notions of privacy.  The simplicity,
   efficiency, and obvious correctness of CTR make it a mandatory member
   in any modern portfolio of SemCPA-secure schemes.  The only
   substantial criticisms of CTR center on its ease of misuse.  First,
   it is imperative that the counter-values that are enciphered are
   never reused.  What is more, these values are 'exposed' to the user
   of CTR, offering ample opportunity to disregard the instructions.
   Second, the mode offers absolutely no authenticity, nonmalleability,
   or chosen-ciphertext-attack (CCA) security.  Users of a symmetric
   scheme who implicitly assume such properties of their
   confidentiality-providing mode are, with CTR, almost certain to get
   caught in their error."

5.8.  AES-GCM

   GCM mode has a security proof - the security notion is AEAD
   (Authenticated Encyrption with Associated Data), which (loosely
   speaking) means that the encryption part is CCA-secure and the
   message and associated data are unforgeable.  There are some

Halpin & Steel            Expires May 23, 2016                  [Page 7]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

   cryptanalytic results on certain instantiations of the scheme, those
   these are not currently thought to pose a practical threat [enisa13].

   Standardised by NIST, GCM is gaining traction in standards such as
   IPsec, MACSec, P1619.1, and TLS [rogaway11evaluation].

5.9.  AES-CMAC

   AES-CMAC has good security proofs (i.e. it has well studied proofs
   with reasonable bounds under standard assumptions)
   [rogaway11evaluation].

5.10.  AES-KW

   AES-KW has received various criticisms, for example being
   inconsistent in its notions of security (requiring IND-CCA from a
   deterministic mode), but though it has no public security proof, it
   has no known attacks either [rogaway06deterministic].  There are
   alternative standards with security proofs such as SIV mode (RFC
   5297)[RFC5297].

5.11.  HMAC

   HMAC has well-studied security proofs, even if the underlying hash
   function is not (weak) collision resistant [bellare06HMAC].

5.12.  DH

   The security of Diffie-Hellman key agreement maps closely to the
   difficulty of the Diffie-Hellman problem.  More than 35 years after
   publication of the DH protocol and despite progress on the discrete
   log problem, there are no publicly known attacks.  Like other plain
   DH modes it offers no authenticity, this must be taken care of
   separately.

5.13.  SHA1

   A procedure is known to obtain SHA-1 collisions in less than 2^62
   operations [wang2005] (since SHA-1 has a fixed 160 bit output, the
   theoretical lower bound is 2^80).  A talk by Marc Stevens outlines a
   procedure requiring 2^60 operations [stevens].  Speculation about
   when practical collisions will be seen ranges from 2018-21
   [schneier].

   Preimage calculation attacks on reduced round SHA-1 currently require
   2^146.2 steps on 44 round SHA-1 and 2^150.6 steps on 48 round (full
   SHA-1 has 80 rounds) and Simon Knellwolf, who worked on these latest
   attacks, notes that given the current rate of progress, efficient

Halpin & Steel            Expires May 23, 2016                  [Page 8]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

   preimage attacks will be seen in 2020 [knellwolf12].

   Finally, some authors consider even the theoretical lower bound on
   collision attacks (2^80) to be too low a security parameter for
   future applications [enisa13].

5.14.  SHA-256, SHA-384, SHA-512

   There are collision and preimage attacks reported on reduced-round
   versions of the SHA-2 family, but currently no practical attacks
   [enisa13].

5.15.  HKDF-CTR

   Security models for password-based key derivation functions are still
   in a state of flux [wen12framework].  However, we note that HKDF has
   security proofs [krawczyk10HKDF].

5.16.  PBKDF2

   PBKDF2 has known weaknesses [yao05kdf].

5.17.  CONCAT

   CONCAT (which refers to the key derivation function defined in
   Section 5.8.1 of NIST SP 800-56A) does not appear to have any
   independent analysis, but is simple and receives approval in the
   ENISA report [enisa13].

6.  Security Considerations

   This informational overview lists some well-known security
   considerations for algorithms in the W3C Web Cryptographic API.  We
   expect these algorithms to be used in particular applications with a
   wide variety of differing threat models for various attacks.  Thus,
   the attacks in-scope and out-of-scope depend on the particular
   protocol, as well as the attacks a protocol is susceptible to and
   those which it protects against.  This note documents per algorithm
   known attacks that are generic to an algorithm, but does not deal
   with the particular level.

7.  IANA Considerations

   This memo includes no request to IANA.  For the algorithms inspected
   in this review, the central authority governing their identifiers is
   the W3C Web Cryptography Working API [W3CWebCryptoCR].  Note that the

Halpin & Steel            Expires May 23, 2016                  [Page 9]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

   W3C Web Cryptography API does map a subset of these algorithm
   identifiers (with additional parameters for the ciphersuites) to the
   IANA registry of JOSE identifiers for algorithms [JWA].

8.  References

8.1.  Normative References

   [JWA]      Jones, M., "JSON Web Algorithms (JWA)", IETF Internet
              Draft, October 2014,
              <http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/>.

   [PKCS11]   Gleeson, S. and C. Zimman, "OASIS PKCS 11", OASIS Working
              Draft draft, November 2014, <https://www.oasis-open.org/
              committees/download.php/54455/pkcs11-base-v2.40-wd11.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
              Authenticated Encryption Using the Advanced Encryption
              Standard (AES)", RFC 5297, October 2008.

   [W3CWebCryptoCR]
              Sleevi, R. and M. Watson, "Web Cryptography API", W3C
              Candidate Recommendation , November 2014,
              <http://www.w3.org/TR/WebCryptoAPI>.

   [W3CWebCryptoLC]
              Sleevi, R. and M. Watson, "Web Cryptography API", W3C Last
              Call Working Draft , March 2014,
              <http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/>.

8.2.  Informative References

   [SteelChoice]
              Steel, G., "Choice of Algorithms in the W3C Crypto API",
              Accessed: 20-Nov-2014, <http://cryptosense.com/
              choice-of-algorithms-in-the-w3c-crypto-api/>.

   [bardou12padding]
              Bardou, R., Focardi, R., Kawamoto, Y., Simionato, L.,
              Steel, G., and Joe-Kai-Tsay, "Efficient padding oracle
              attacks on cryptographic hardware", In Advances in
              Cryptology: Proceedings of CRYPTO '12, volume 7417 of
              LNCS, pages 608-625. Springer, 2012. , 2012.

Halpin & Steel            Expires May 23, 2016                 [Page 10]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

   [barthe2009POPL]
              Barthe, G., Gregoire, B., and S. Zanella-Beguelin, "Formal
              certification of code-based cryptographic proofs", In 36th
              ACM SIGPLAN-SIGACT Symposium on Principles of Programming
              Languages, POPL 2009, pages 90-101. ACM, 2009. , 2009,
              <http://dx.doi.org/10.1145/1480881.1480894>.

   [bellare06HMAC]
              Bellare, M., "New proofs for MAC and HMAC: security
              without collision-resistance", In Cynthia Dwork, editor,
              CRYPTO, volume 4117 of Lecture Notes in Computer Science,
              pages 602-619. Springer, 2006 , 2006.

   [bellare96eurocrypt]
              Bellare, M. and P. Rogaway, "The exact security of digital
              signatures-how to sign with rsa and rabin", In Proceedings
              of the 15th Annual International Conference on Theory and
              Application of Cryptographic Techniques, EUROCRYPT'96,
              pages 399-416, Berlin, Heidelberg, 1996. Springer-
              Verlag. , 1996,
              <http://dl.acm.org/citation.cfm?id=1754495.1754541>.

   [bleichenbacher98]
              Bleichenbacher, D., "Chosen ciphertext attacks against
              protocols based on the RSA encryption standard", In
              Advances in Cryptology: Proceedings of CRYPTO '98, volume
              1462 of Lecture Notes in Computer Science,pages 1-12,
              1998. , 1998.

   [boneh01crypto]
              Boneh, D. and I. Shparlinski, "On the unpredictability of
              bits of the elliptic curve diffie-hellman scheme", In Joe
              Kilian, editor, Advances in Cryptology - CRYPTO 2001,
              volume 2139 of Lecture Notes in Computer Science, pages
              201-212. Springer Berlin Heidelberg, 2001. , 2001,
              <http://dx.doi.org/10.1007/3-540-44647-8_12>.

   [email]    Kaliski, B., "Raising the Standard for RSA Signatures:
              RSA-PSS", Accessed: 11-Nov-2014, <https://web.archive.org/
              web/20130523004555/http://www.rsa.com/rsalabs/
              node.asp?id=2005>.

   [enisa13]  Smart, N., Rijmen, V., Warinschi, B., and G. Watson,
              "Algorithms, key sizes and parameters report: 2013
              recommendations", Technical report, October 2013. ENISA
              Report. Version 1.0.  , 2013.

   [fujisaki04OAEP]

Halpin & Steel            Expires May 23, 2016                 [Page 11]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

              Fujisaki, E., Okamoto, T., Pointcheval, D., and J. Stern,
              "RSA-OAEP is secure under the RSA assumption", Journal.
              Cryptol., 17(2):81-104, March 2004 , 2004,
              <http://dx.doi.org/10.1007/s00145-002-0204-y>.

   [jager12bleichenbacher]
              Jager, T., Schinzel, S., and J. Somorovsky,
              "Bleichenbacher's attack strikes again: breaking PKCS#1
              v1.5 in XML encryption", In Sara Foresti, Moti Yung, and
              Fabio Martinelli, editors, Computer Security - ESORICS
              2012, volume 7459 of Lecture Notes in Computer Science,
              pages 752-769. Springer Berlin Heidelberg, 2012. , 2012,
              <http://dx.doi.org/10.1007/978-3-642-33167-1_43>.

   [kaminsky10]
              Kaminsky, A., Kurdziel, M., and S. Radziszowski, "An
              overview of cryptanalysis research for the advanced
              encryption standard", In Military Communications
              Conference, 2010 - MILCOM 2010. , 2010.

   [knellwolf12]
              Knellwolf, S. and D. Khovratovich, "New Preimage Attacks
              against Reduced SHA-1", In Advances in Cryptology - CRYPTO
              2012, volume 7417 of Lecture Notes in Computer Science,
              pages 367-383. Springer Berlin Heidelberg, 2012. , 2012,
              <http://www.iacr.org/cryptodb/data/
              paper.php?pubkey=24323>.

   [krawczyk10HKDF]
              Krawczyk, H., "Cryptographic extraction and key
              derivation: the HKDF scheme", In Tal Rabin, editor,
              CRYPTO, volume 6223 of Lecture Notes in Computer Science,
              pages 631-648. Springer, 2010.  , 2010.

   [manger01]
              Manger, J., "A chosen ciphertext attack on rsa optimal
              asymmetric encryption padding (OAEP) as standardized in
              PKCS #1 v2.0", In Joe Kilian, editor, Advances in
              Cryptology CRYPTO 2001, volume 2139 of Lecture Notes in
              Computer Science, pages 230-238. Springer Berlin /
              Heidelberg, 2001 , 2001.

   [mitchell05cbc]
              Mitchell, C., "Error oracle attacks on CBC mode: is there
              a future for CBC mode encryption?", In J. et al. Zhou,
              editor, ISC 2005, volume 3650 in Lecture Notes in Computer
              Science, pages 244-258, 2005. , 2005.

Halpin & Steel            Expires May 23, 2016                 [Page 12]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

   [paterson04padding]
              Paterson, K. and A. Yau, "Padding oracle attacks on the
              ISO CBC mode encryption standard", In T. Okamoto, editor,
              RSA '04 Cryptography Track, number 2964 in LNCS, pages
              305-323. Springer, 2004. , 2004.

   [rizzo10USENIX]
              Rizzo, J. and T. Duong, "Practical padding oracle
              attacks", WOOT'10, pages 1-8, Berkeley, CA, USA, 2010.
              USENIX Association , 2010,
              <http://portal.acm.org/citation.cfm?id=1925004.1925008>.

   [rogaway06deterministic]
              Rogaway, P. and T. Shrimpton, "Deterministic
              authenticated-encryption: a provable-security treatment of
              the key-wrap problem", In Advances in Cryptology
              (EUROCRYPT '06), volume 4004 of LNCS, pages 373-390,
              2006. , 2006, <https://eprint.iacr.org/2006/221.pdf>.

   [rogaway11evaluation]
              Rogaway, P., "Evaluation of some blockcipher modes of
              operation", Technical report, University of California,
              Davis, February 2011. Evaluation carried out for the
              Cryptography Research and Evaluation Committees (CRYPTREC)
              for the Government of Japan. , 2011.

   [schneier]
              Schneier, B., "When Will We See Collisions for SHA-1?",
              Accessed: 11-Nov-2014, <https://www.schneier.com/blog/
              archives/2012/10/when_will_we_se.html>.

   [stevens]  Stevens, M., "Cryptanalysis of MD5 and SHA-1", Accessed:
               11-Nov-2014, <http://2012.sharcs.org/slides/stevens.pdf>.

   [vaudenay02]
              Vaudenay, S., "Security flaws induced by CBC padding -
              applications to SSL, IPSEC, WTLS ...", In Lars R. Knudsen,
              editor, EUROCRYPT, volume 2332 of Lecture Notes in
              Computer Science, pages 534-546. Springer, 2002. , 2002.

   [vaudenay03PKC]
              Vaudenay, S., "The security of DSA and ECDSA", In Yvo G.
              Desmedt, editor, Public Key Cryptography - PKC 2003,
              volume 2567 of Lecture Notes in Computer Science, pages
              309-323. Springer Berlin Heidelberg, 2002 , 2002,
              <http://dx.doi.org/10.1007/3-540-36288-6_23>.

   [wang2005]

Halpin & Steel            Expires May 23, 2016                 [Page 13]

Internet-Draft    W3C WebCrypto Security Considerations    November 2015

              Wang, X., Yin, Y., and H. Yu, "Finding collisions in the
              full SHA-1", In Proceedings of the 25th Annual
              International Conference on Advances in Cryptology,
              CRYPTO'05, pages 17-36, Berlin, Heidelberg, 2005.
              Springer-Verlag , 2005,
              <http://dx.doi.org/10.1007/11535218_2>.

   [wen12framework]
              Wen, C., Dawson, E., Nieto, J., and L. Simpson, "A
              framework for security analysis of key derivation
              functions", In Mark Dermot Ryan, Ben Smyth, and Guilin
              Wang, editors, ISPEC, volume 7232 of Lecture Notes in
              Computer Science, pages 199-216. Springer, 2012 , 2012.

   [yao05kdf]
              Yao, F. and Y. Yin, "Design and analysis of password-based
              key derivation functions", In Alfred Menezes, editor, CT-
              RSA, volume 3376 of Lecture Notes in Computer Science,
              pages 245-261. Springer, 2005 , 2005.

Appendix A.  Acknowledgments

   Special thanks to Ryan Sleevi and Mark Watson for their work on the
   Web Cryptography API, as well as Rich Salz for bringing up the issue
   of algorithm-specific security considerations.  Thanks to Kelsey
   Cairns for helping with the formal analysis.  Graham Steel authored
   the original version of this report [SteelChoice], and Harry Halpin
   from W3C/MIT agreed to edit and keep the document up to date.

Authors' Addresses

   Harry Halpin (editor)
   W3C/MIT

   Email: [email-masked]
   URI:   http://www.ibiblio.org/hhalpin/

   Graham Steel
   Cryptosense/INRIA

   Email: [email-masked]
   URI:   http://www.lsv.ens-cachan.fr/~steel/

Halpin & Steel            Expires May 23, 2016                 [Page 14]

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 20 Nov 2014 10:59:27 -0500

Great, this is good progress.

> Note that draft, while attempting

I think you mean "Note that /this/ draft"
 
If this document is intended to be stand-alone, you need to describe the columns in Table 1.  Last line of that table has an extra close-paren.

Shouldn't sec4 be right after 1?

I think you should either do just-webcrypto, or explicitly say 'many/most ietf rfcs'  My pref is just webcrypto.  Drop pkcs1.5 et al.  Or move it and the non-WebCrypto ones to an appendix.

I think you need a table of acronyms near the beginning; CCA is used in table 1 for example.  And redefined in Rogaways' quote in 5.7

This is a very useful document, thanks.
--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Watson Ladd <[email-masked]>
Date: Thu, 20 Nov 2014 08:00:18 -0800

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

This says ECDSA is weak, and doesn't recommend future use Huh? MACs
are necessary for use with anything not AES-GCM, and this isn't
mentioned, nor is the correct way to compose described. The DH
description is just wrong: NFS has made a tremendous dent in the
security of genus 0 Diffie-Hellman. The security results for ECDH
cited aren't ones that actually matter.

There is no guidance on key size, which can make even the strongest scheme weak.

One might think HKDF2 is the right way to store a hashed password from
reading this. They would be wrong, as it's easy to search all
possibilities. PBKDF2 isn't much better, but you have a fighting
chance.

Other then that I didn't find any problems.

Sincerely,
Watson Ladd

---

From: Jonathan Berliner <[email-masked]>
Date: Thu, 20 Nov 2014 11:24:42 -0500

I'm relatively new to this group so take this with some salt, but this
bothered me:

I don't like the usage of "nonce" and "random" in these sentences:
"AES-CBC mode is not CCA secure. It is secure against chosen plaintext
attacks (CPA-secure) if the IV is random, but not if the IV is a
nonce[rogaway11evaluation]."

"AES-CFB is not CCA secure. It is CPA-secure if the IV is random, but
not if the IV is a nonce [rogaway11evaluation]."

I read Rogaway's paper
(http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf), but I think we
can define this better:

"Nonce" - a value/number/string used only once.
"Random number" - a value/number/string that doesn't follow a pattern
(or what-have-you).

This doesn't mean that "nonces" are insecure. "Non-random nonces" are
insecure, but "random nonces" are secure. According to the flow of the
document, "random IVs" are also insecure, because they may be used
more than once.

I think I understood Rogaway's intent here, that non-randomness is the
problem, not one-timeness. Based on a cursory survey of parlance used
on the Internet, I think others would be confused by this, because
"nonces" can also be "random."

Jonathan

On Thu, Nov 20, 2014 at 11:00 AM, Watson Ladd <[email-masked]> wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Nov 2014 08:57:43 -0800

If you want this to be a CFRG-edited draft, that's great. As a few people have pointed out, it has some deep flaws, and having lots of eyes on it with regular updates would be valuable.

--Paul Hoffman

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 20 Nov 2014 16:58:45 +0000

>  -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Jonathan Berliner
> Sent: Thursday, November 20, 2014 11:25 AM
> To: Watson Ladd
> Cc: [email-masked]
> Subject: Re: [Cfrg] Proposed Informational Note: Security Guidelines for
> Cryptographic Algorithms in the W3C Web Cryptography API
> 
> I'm relatively new to this group so take this with some salt, but this bothered
> me:
> 
> "AES-CFB is not CCA secure. It is CPA-secure if the IV is random, but not if the
> IV is a nonce [rogaway11evaluation]."
> 
> I read Rogaway's paper
> "Random number" - a value/number/string that doesn't follow a pattern (or
> what-have-you).
> 
> insecure, but "random nonces" are secure.

I don't think that Rogaway wants to imply that using nonces necessarily imply insecurity; instead, what he is saying is that if we assume that we use nonces (and make no other assumption beyond that), that does not imply security.  That is, we're not looking for things we know will lead to weakness; we're looking for the necessary assumptions we need to make to know that the cryptography is strong.

> According to the flow of the
> document, "random IVs" are also insecure, because they may be used more
> than once.

Actually, if the IV's are actually chosen at random, we can show that the probability of selecting the same IV twice is negligible.

> problem, not one-timeness. Based on a cursory survey of parlance used on
> the Internet, I think others would be confused by this, because "nonces" can
> also be "random."

Just because others use terminology is an imprecise way doesn't mean we should.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 20 Nov 2014 18:27:42 +0100

On 20/11/2014 17:58, Scott Fluhrer (sfluhrer) wrote:
>> [...]
> I don't think that Rogaway wants to imply that using nonces necessarily imply
> insecurity; instead, what he is saying is that if we assume that we use
> nonces (and make no other assumption beyond that), that does not imply
> security.  That is, we're not looking for things we know will lead to
> weakness; we're looking for the necessary assumptions we need to make to know
> that the cryptography is strong.
> 
I agree, but I think the sentence quoted above would be clearer this way:

"AES-CFB is not CCA secure. It is CPA-secure if the IV is random, but it is not
enough for the IV be be a nonce [rogaway11evaluation]."

>> According to the flow of the document, "random IVs" are also insecure,
>> because they may be used more than once.
> 
> Actually, if the IV's are actually chosen at random, we can show that the
> probability of selecting the same IV twice is negligible.
> 
It depends on the length of the IV and how many packets you encrypt with the
same keys. For example, with GCM as used in TLS, only 64 bits of IV are possibly
random. This means, with random IVs, you can expect collisions if you send more
than 2^32 records, which can totally happen in some usages of TLS.

Manuel.

---

From: David Gil <[email-masked]>
Date: Thu, 20 Nov 2014 09:50:22 -0800

> enough for the IV be be a nonce [rogaway11evaluation]."

Could we please just use the terminology that every paper on crypto uses?

Standard jargon: IVs are always uniform (computationally hard 
pseudo)random strings. Nonces are strings that are used only once.

As Watson noted, an IV of sufficient length is with high probability
a nonce; best is to set len(IV) = 2*s, where s is the target security
strength.

---

From: Harry Halpin <[email-masked]>
Date: Thu, 20 Nov 2014 19:23:36 +0100

> If you want this to be a CFRG-edited draft, that's great. As a few people have pointed out, it has some deep flaws, and having lots of eyes on it with regular updates would be valuable.

Yes, that's the plan, as W3C will need the eyes of CFRG on it in the
future as well as new attacks and proofs are discovered.

We'll just watch the discussions on the preliminary version come in and
revise within a week or two unless there is serious disagreement between
members of CFRG. If theres is more or less agreement, I'll make the
edits and then formally submit this to be a CFRG edited draft.

   cheers,
        harry

---

From: Dan Brown <[email-masked]>
Date: Thu, 20 Nov 2014 20:11:32 +0000

> From: Cfrg [mailto:[email-masked]] On Behalf Of Harry Halpin
> 
revise
> within a week or two unless there is serious disagreement between members
> of CFRG. If theres is more or less agreement, I'll make the edits and then
> formally submit this to be a CFRG edited draft.
> 

I disagree with the "NO" for ECDSA for future use..  The larger reason is
that only alternative signature algorithms in the document are RSA-based,
whereas, by contrast, TLS is moving from RSA to ECC.  The smaller reason is
that ECDSA seems, to me, quite secure for future use if used properly.

I disagree with the rationale against ECDSA about the "weakness" of the
provable security results. Here, I may be biased, being an author of such
works.  

I disagree with the claims regarding Vaudenay's domain parameter attack.
For prime fields: first, as Vaudenay himself writes, the attack is not known
to be effective in the case of prime fields; second, CFRG is now undertaking
a recommendation for new curves.  For binary fields: first, they are being
used much less; second, the usual representations are chosen from a rather
"rigid" list, rather than an arbitrary list as described in the attack.
Specifically, SEC1 defaults a unique representation per field, using
trinomial if possible, else pentanomial, with degrees of the middle terms of
minimized.  For conveying elliptic curve parameters using ASN.1, usually one
just uses an OID which requires the default representation, or alternatively
one can specify the curve details which requires a normal basis, a
trinomial, or a pentanomial.  It seems that ANSI X9.62-2005 now has similar
requirements for the field representations.  Therefore, I think the claim
that the field representation can be chosen maliciously is inconsistent with
the SECG and ANSI standards.

I can elaborate and discuss the points above further, if needed. I believe
that CFRG now has a focus on recommending a new elliptic curve, so I have
tried to be brief here.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 20 Nov 2014 13:09:14 -0800 (PST)

Hello,

> to maintaining this note as much as possible.

[snip]

>    alternative standards with security proofs such as SIV mode (RFC

  This is very puzzling. Why recommend AES-KW if you acknowledge
there is a better alternative?

  Not only is there no security proof for AES-KW, it is also clunky to
use because it imposes restrictions on the size of the input data to
be wrapped. SIV imposes no restrictions on size and does not require
any kind of padding. And the whole discussion of nonces in this thread,
and the used-once issue with using a randomly selected nonce, doesn't
apply to SIV in its deterministic mode. No nonce? No problem.

  When making suggestions to developers to choose the right
cryptographic algorithm (which this draft intends to do) you should
ensure that to the fullest extent possible that misuse resistant options
are favored over their fragile alternatives. SIV requires less from the
developer than its alternative.

  As a bulk data encrypter SIV is a solid 2nd place to something like
GCM but as a tool for key exchange where selected portions of a
message need protection and the requirement for injection of good
randomness isn't strictly necessary, SIV excels. It works as a secure
AEAD scheme in its deterministic mode (with a slight qualification
when the same data and same AAD are protected by the same key)
and also works if you can supply a good nonce. It's the Swiss Army
Knife of crypto protocol development.

  I strongly suggest you swap AES-SIV for AES-KW in your table and
in your recommendations.

  regards,

  Dan.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 21 Nov 2014 08:55:50 +0100

> pseudo)random strings. Nonces are strings that are used only once.
Sure. How would you word the above sentence?

> a nonce; best is to set len(IV) = 2*s, where s is the target security
Yes, and as I noted, there are existing cases where this length condition is not
satisfied.

Manuel.