[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          D. McGrew
Internet-Draft                                                 A. Grieco
Intended status: Experimental                                      Cisco
Expires: July 29, 2013                                        Y. Sheffer
                                                        January 25, 2013

              Selection of Future Cryptographic Standards


   The Advanced Encryption Standard (AES) is extensively used and is
   widely believed to provide security that is more than adequate.
   Several other cipher designs have been proposed for use in standards,
   and new designs continue to be developed, while consideration of cost
   and complexity impels that the number of mandatory-to-implement
   ciphers be minimized.  This note outlines an approach to the
   selection of cryptographic algorithms that best serves the needs of
   the users of cryptography: AES should continue in its role as the
   mandatory-to-implement cipher, while other cipher designs should be
   reviewed with the goal of selecting a single standby cipher.  If
   future advances in the science of cryptanalysis uncover security
   issues with the AES, the standby cipher will be ready for adoption as
   its replacement.

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 July 29, 2013.

Copyright Notice

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

McGrew, et al.            Expires July 29, 2013                 [Page 1]

Internet-Draft          Standby Cipher Selection            January 2013

   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.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Requirements Language  . . . . . . . . . . . . . . . . . . .  3
   2.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    The (Over)abundance of Ciphers . . . . . . . . . . . . . . .  3
   4.    Algorithm Agility and Security Policies  . . . . . . . . . .  4
   5.    Cryptographic Protocols  . . . . . . . . . . . . . . . . . .  5
   6.    A Standby Algorithm  . . . . . . . . . . . . . . . . . . . .  6
   6.1.  Security Considerations  . . . . . . . . . . . . . . . . . .  7
   7.    Recommendations  . . . . . . . . . . . . . . . . . . . . . .  8
   8.    Other Considerations . . . . . . . . . . . . . . . . . . . .  9
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  9
   10.   Security Considerations  . . . . . . . . . . . . . . . . . .  9
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 10
   12.1. Normative References . . . . . . . . . . . . . . . . . . . . 10
   12.2. Informative References . . . . . . . . . . . . . . . . . . . 10
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10

McGrew, et al.            Expires July 29, 2013                 [Page 2]

Internet-Draft          Standby Cipher Selection            January 2013

1.  Introduction

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  Background

   The modern cryptography industry relies on peer-reviewed algorithms
   and protocols.  The robustness of a cryptographic algorithm can only
   be established after experts have reviewed it and no weakness in the
   algorithm has been found.  Many advanced techniques have been
   developed for designing algorithms and analyzing their security.

   The reliance that the cryptographic industry has on expert review has
   caused it to put a premium value on open publication, open peer
   review, and open standards.  The process that selected the Advanced
   Encryption Standard (AES, [FIPS-197]), was open and transparent.
   Fifteen submissions were accepted from around the world (though the
   process was managed by the National Institute of Standards and
   Technology (NIST) of the United States), and their security and
   efficiency was widely analyzed and discussed at three public
   workshops and other peer- reviewed venues over the course of four
   years, before the Belgian submission was selected.  The caution,
   thoroughness, and openness of the selection process inspired
   confidence on the part of standards organizations, and the AES cipher
   was adopted by many international standards, including those in the
   IETF and the IEEE.

   Standards organizations are free to select the cryptographic
   algorithms that meet their requirements for security and efficiency.
   Currently, AES is the most commonly used cipher, because of the
   confidence that the industry has in its design and because its wide
   use ensures wide availability of implementations.  The Triple Data
   Encryption Standard (3DES) is a legacy algorithm that is still in
   use, as is the RC4 stream cipher.

3.  The (Over)abundance of Ciphers

      The nice thing about standards is that there are so many of them
      to choose from. - Andrew S. Tanenbaum

   Several other ciphers have been proposed for use in IETF protocols in
   recent years, including SEED, ARIA, Camellia, CLEFIA and GOST.  In

McGrew, et al.            Expires July 29, 2013                 [Page 3]

Internet-Draft          Standby Cipher Selection            January 2013

   some other instances, new ciphers have been introduced as unpublished
   extensions to IETF standards (as was originally the case with ARIA)
   or as part of new, non-standard protocols (such as WAPI).  These
   ciphers, as well as other ones, have been proposed in other contexts,
   such as ISO/IEC JTC 1/SC 27 Working Group on Cryptography and
   Security Mechanisms, the Japanese Cryptography Research and
   Evaluation Committees (CRYPTREC), and the European Network of
   Excellence in Cryptology (ECRYPT) II project.  The availability of so
   many cipher designs that appear to have adequate security is
   encouraging.  However, it would be counterproductive to require or
   urge that every implementation of security protocols such as IPsec or
   TLS include multiple new ciphers.  That would increase the cost and
   complexity of those protocols while contributing little benefit to
   the Internet community.

   Each additional cipher that an implementation supports will increase
   the cost of its development, testing, and validation.
   Implementations that use hardware to achieve scalability and
   throughput will require additional circuits for each cipher.
   Additionally, architectures deployed today rely on more than just two
   endpoints having the same cipher support.  Instead, they involve
   ecosystems of capabilities to deliver secured communications.  For
   example, devices such as load balancers, authentication servers, etc.
   are all required to support large scale deployments of services in
   many architectures, and these devices would be required to implement
   all possible ciphers.  Finally, if a multiplicity of ciphers is used
   in practice, it will drive up operational costs as well, because the
   policy that determines when the new cipher must be used will need to
   be put into effect.

4.  Algorithm Agility and Security Policies

   Standard cryptographic protocols, such as Transport Layer Security
   (TLS) and Internet Protocol Security (IPsec), include functionality
   that allows two endpoints to dynamically negotiate the algorithms
   that are used in a particular session.  This feature is called
   algorithm agility, and it is important because it enables a new
   algorithm to be easily introduced in a protocol, while preserving
   interoperability between devices that support the new algorithm and
   ones that do not.  Algorithm agility is crucial to security because
   it allows for the replacement of algorithms that are found to have
   cryptographic weaknesses.

   The algorithm negotiation capability can also be used to allow
   implementations to support multiple algorithms, and dynamically
   decide which algorithms to use.  In principle, it is possible to have
   different devices each support different sets of algorithms, as long

McGrew, et al.            Expires July 29, 2013                 [Page 4]

Internet-Draft          Standby Cipher Selection            January 2013

   as each pair of sets is overlapping.  However, it is highly desirable
   to minimize the number of algorithms that must be supported by an
   implementation, because of the complexity and administrative burden
   of managing the policy associated with a multitude of algorithms.
   Because of these factors, most standards choose to mandate only a
   single algorithm that must be implemented by all devices, despite the
   availability of a negotiation mechanism.  In addition, cryptographic
   negotiation also establishes other algorithms and parameters to be
   used, such as key establishment, authentication, pseudorandom
   functions, and key sizes.

   Algorithm agility also allows the use of ciphers other than the
   mandatory-to-implement cipher within specialized communities of
   interest.  This is a valid use of that capability, but it should be
   noted, however, that there is complexity and cost in the use of
   elaborate security policies.  If a community of interest requires
   that a particular cipher be used within that community, but allows
   the use of other ciphers when devices from that community communicate
   outside that community, it will need to put this policy into practice
   on all devices within the community.  This process will not be
   trivial or easy to execute; there will need to be a mechanism by
   which devices in the community can identify whether or not a
   communicant is also inside the community.  The situation is simpler
   when a cipher is used only within a community of interest, and the
   devices in that community are used to communicate only with other
   devices in the same community.  In this case, there is no need for a
   mechanism that determines which other devices are also in the
   community; each device in the community can be configured to only use
   the favored cipher.

5.  Cryptographic Protocols

   The IETF should allow the use of specialized algorithms within the
   cryptographic protocol standards that it defines.  To do otherwise
   could encourage the proliferation of protocol standards, which is a
   worse situation than the proliferation of cipher standards.  It is
   highly desirable to limit the number of cryptographic protocols.  It
   is much harder to replace a protocol, or to support multiple
   protocols, as opposed to replacing a cryptographic algorithm.  An
   algorithm may have high complexity, but the complexity is well
   isolated through a simple interface.  In contrast, the complexity of
   a protocol is not at all isolated; it touches the protocol layers
   above and below it, and an efficient protocol implementation will
   closely interact with the system on which it runs.

   It is far better to add a new feature or algorithm to an existing
   cryptographic protocol than to introduce an entirely new protocol.

McGrew, et al.            Expires July 29, 2013                 [Page 5]

Internet-Draft          Standby Cipher Selection            January 2013

   By way of example, the TLS protocol was extended so that it can
   protect UDP traffic as well as TCP traffic, resulting in the Datagram
   TLS (DTLS) protocol.  This standards action was widely perceived as
   being preferable to the introduction of a new protocol that would
   protected only UDP.

6.  A Standby Algorithm

   The industry is in the fortunate position that the main requirements
   for a mandatory global cipher and algorithm agility are met by
   current standards for communication security protocols.  Many
   additional ciphers have been proposed for use in these standards.  It
   may be useful for the global crypto standards community to seek
   algorithm diversity by selecting a cipher to be used as a standby or
   fallback, in case of the possibility that future advances in the
   science of cryptanalysis might uncover security issues with the
   current global standard cipher.  The implementation of the standby
   cipher should not be required, but could be recommended for
   implementation by security protocol standards.  In the terms of RFC
   2119, the standby algorithm SHOULD be implemented.

   The process for the selection of a standby should meet the same
   Exacting criteria as the global standard cipher, to assure its
   technical merit.  Ideally, a standby cipher should be selected in
   advance of when it is needed.  That cipher should be chosen after
   extensive public review and analysis, in which time is allowed for
   significant scientific scrutiny and investigation.  The cipher should
   demonstrate its strength through the publication of attacks that work
   only against a small number of rounds, since an absence of published
   attacks may indicate an absence of cryptanalysis instead of an
   absence of weaknesses.  The best cipher designs from around the world
   should be considered, and analyses should be openly published and
   widely disseminated.  Only a single standby cipher should be
   recommended, to minimize the cost of implementation and maximize
   interoperability.  To be recommended as a standby, an algorithm
   should meet all of the criteria set out for the AES:

   o  security,
   o  computational efficiency,
   o  memory requirements,
   o  hardware and software suitability,
   o  simplicity,
   o  flexibility, and
   o  licensing requirements; in particular, it should be available
      worldwide on a royalty-free basis.

   In addition to the AES requirements, there are requirements that are

McGrew, et al.            Expires July 29, 2013                 [Page 6]

Internet-Draft          Standby Cipher Selection            January 2013

   particular to a cipher that would serve as a standby to the AES:

   o  it should have a design that is as independent of that of the AES
      as is possible, so that advances in cryptanalysis that lower the
      effective security of one design have as little effect as possible
      on the other one, and
   o  it should also perform well on existing hardware that is optimized
      for AES implementation.

   The final criterion, performance on existing AES optimized hardware,
   refers to the consideration for standby algorithm performance when
   executing in existing hardware today.  The goal of this criteria
   would be to select a cipher that performs well today on existing
   hardware implementations, many of which have optimized AES
   implementations.  This constraint would provide for a more timely
   transition to the standby cipher because no new hardware optimization
   would be needed.  However, this criteria is focused on short term
   deployment and does so at a cost of constraining the design of the
   standby cipher.  A longer term view would remove this criteria and
   consider all ciphers that are practical to implement without specific
   consideration to applicability to existing hardware optimization.  In
   doing so, designs considered for the standby cipher would be more
   flexible and likely positively impact considerations in other
   criteria categories, but could also increase adoption time.  The
   authors note this inherent conflict associated with this criteria and
   request the community's opinion about resolution to this issue.

   The Triple-DES (TDES) algorithm has a 64-bit block size, and because
   of this, is not suitable for securing very large volumes of data
   [coll64bit].  It also is significantly slower in software, and less
   efficient in hardware.  Thus TDES is not a suitable standby cipher.
   This is an additional motivation for the selection of a new standby

6.1.  Security Considerations

   There is no known weakness in AES that affects its practical
   security.  Biclique cryptanalysis add citation can be used to shave
   one or two bytes off of the theoretical strength of the cipher, in
   scenarios in which the attacker can cause the encryption/decryption
   of 2^88 chosen plaintexts/ciphertexts of its choice.  This attack has
   no relevance on the uses of AES in conventional block cipher modes of
   operation, in which 2^64 blocks is the accepted maximum number that
   should be encrypted with any key.  There have been related key
   attacks against AES-192 and AES-256, and suggestions that the key
   schedule of that algorithm is not as strong as would be desirable.
   Thus three important criteria for a standby cipher are that there
   should be an absence of related key attacks against it, there should

McGrew, et al.            Expires July 29, 2013                 [Page 7]

Internet-Draft          Standby Cipher Selection            January 2013

   be especially high confidence in its 192 and 256 bit variants, and
   the key schedule should be perceived to be strong.  The major goal of
   a standby cipher is to be secure even if the AES proves vulnerable to
   future advances in cryptanalysis.  Thus, a standby cipher should not
   follow a design strategy that is identical to that of the AES.  Block
   ciphers with a 64-bit block have a very significantly lower security
   level than those with a 128-bit block, and thus should be strongly

7.  Recommendations

   The industry and the IETF should encourage the use of existing
   security protocols, and to this end, the IETF should allow the
   publication of documents describing the use of ciphers in IETF
   standards, even when those ciphers have only a small community of
   interest.  This policy was clarified by the Security Area Directors
   at IETF78, and it should be continued.  However, the IETF should
   explicitly reject the idea that each community of interest gets to
   have its favored cipher be added to the list of mandatory-to-
   implement ciphers.  It is important to clarify the difference between
   algorithms that MUST be implemented in a particular protocol from the
   algorithms that MAY be implemented.  We suggest that:

   o  The IETF and IRTF Crypto Forum Research Group (CFRG) should
      identify the technical requirements that a standby cipher should
      meet, and provide this input to the international cryptographic
      community.  This effort will be led by the CFRG, with the goal
      that the requirement document be published as an RFC no later than
      XXX months after the current document is published.
   o  The IETF and IRTF Crypto Forum Research Group (CFRG) should
      identify the technical requirements that a standby cipher should
      meet, and provide this input to the international cryptographic
   o  Ideally, the process will result in the IETF-wide selection of a
      single standby cipher, followed by a lengthy process of individual
      working groups adopting this choice for their specific protocols.
      However the CFRG may also reach the unfortunate conclusion that no
      current algorithm fulfills the requirements.
   o  The IETF should encourage and support the discussion and analysis
      of a standby cipher through open and public processes.
   o  Communities of interest that seek to introduce new ciphers to the
      industry should be encouraged to participate in international
      standards and other public processes for discussion, review,
      analysis, presentation, and dissemination of results.

McGrew, et al.            Expires July 29, 2013                 [Page 8]

Internet-Draft          Standby Cipher Selection            January 2013

8.  Other Considerations

   Above we discussed only symmetric ciphers.  Similar considerations
   apply to hashing, message authentication, signatures, key exchange,
   and asymmetric encryption.  It is highly desirable to limit the
   number of new cryptographic algorithms that are introduced into
   standards.  The Galois/Counter Mode (GCM) of operation for block
   ciphers and the Counter and CBC-MAC (CCM) Mode of operation for block
   ciphers provide both encryption and authentication; they do away with
   the need to implement a separate message authentication code such as
   HMAC.  This is a strong advantage in the context of limiting the
   number of algorithms.

   It could reasonably be argued that instead of selecting a block
   cipher, the standards community should be selecting an Authenticated
   Encryption with Associated Data (AEAD) mechanism [RFC5116].  The
   cryptographic algorithm design community has identified AEAD as the
   best paradigm for symmetric cryptography, and there is theoretical
   interest in the development of new algorithms in this area, as
   indicated by the recent Directions in Authenticated Ciphers workshop.
   However, it is not yet clear that such a mechanism could be adopted
   as easily as a new block cipher.

   The hash algorithm contest recently completed by NIST created a
   selection for SHA-3.  SHA-256 remains the standard, mandatory to
   implement hash algorithm, but SHA-3 could be considered the standby
   hash algorithm.

9.  IANA Considerations

   This memo includes no request to IANA.

10.  Security Considerations

   This note analyzes the considerations in the selection of
   cryptographic algorithms for future use.  The appropriate selection
   of algorithms is important for security.

11.  Acknowledgements

   This document was prepared using the lyx2rfc tool, and we would like
   to thank Nico Williams, its author.

12.  References

McGrew, et al.            Expires July 29, 2013                 [Page 9]

Internet-Draft          Standby Cipher Selection            January 2013

12.1.  Normative References

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

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, January 2008.

12.2.  Informative References

              National Institute of Standards and Technology (NIST),
              "Advanced Encryption Standard (AES)", FIPS PUB 197,
              November 2001.

              McGrew, D., "Impossible plaintext cryptanalysis and
              probable-plaintext collision attacks of 64-bit block
              cipher modes", IACR Eprint Archive 2012/623,
              November 2012, <http://eprint.iacr.org/2012/623.pdf>.

Authors' Addresses

   David McGrew
   Cisco Systems, Inc.
   13600 Dulles Technology Drive
   Herndon, VA  20171

   Email: mcgrew@cisco.com

   Anthony Grieco
   Cisco Systems, Inc.
   7025 Kit Creek Road
   RTP, NC  27709

   Email: agrieco@cisco.com

McGrew, et al.            Expires July 29, 2013                [Page 10]

Internet-Draft          Standby Cipher Selection            January 2013

   Yaron Sheffer
   10 Yirmiyahu St.
   Ramat HaSharon  47298

   Email: yaronf.ietf@gmail.com

McGrew, et al.            Expires July 29, 2013                [Page 11]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/