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

"Dan Harkins" <dharkins@lounge.org> Thu, 20 November 2014 21:09 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057981A700E for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 13:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Level:
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bweJ_VmFESYZ for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 13:09:15 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F3B241A6F99 for <cfrg@irtf.org>; Thu, 20 Nov 2014 13:09:14 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 885AA1022400A; Thu, 20 Nov 2014 13:09:14 -0800 (PST)
Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 20 Nov 2014 13:09:14 -0800 (PST)
Message-ID: <3c4ed9ea116bb31a4041a974838922ff.squirrel@www.trepanning.net>
In-Reply-To: <546E0AE5.3040601@w3.org>
References: <546E0AE5.3040601@w3.org>
Date: Thu, 20 Nov 2014 13:09:14 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Harry Halpin <hhalpin@w3.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/I_8PBZpVJqu_gTgW9IFl0HaTvsc
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 21:09:21 -0000

  Hello,

On Thu, November 20, 2014 7:38 am, Harry Halpin wrote:
> 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.

[snip]

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

  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.

>
> 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: harry@w3c.org
>    URI:   http://www.ibiblio.org/hhalpin/
>
>
>    Graham Steel
>    Cryptosense/INRIA
>
>    Email: Graham.Steel@inria.fr
>    URI:   http://www.lsv.ens-cachan.fr/~steel/
>
>
>
>
>
>
> Halpin & Steel            Expires May 23, 2016                 [Page 14]
> 
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>