Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
draft-iab-crypto-alg-agility-05

The information below is for an old version of the document
Document Type Active Internet-Draft (individual in sec area)
Last updated 2015-06-04
Replaces draft-housley-crypto-alg-agility
Stream IETF
Intended RFC status Best Current Practice
Formats plain text pdf html bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd No shepherd assigned
IESG IESG state AD is watching
Consensus Boilerplate Unknown
Telechat date
Responsible AD Stephen Farrell
Send notices to draft-iab-crypto-alg-agility@ietf.org, draft-iab-crypto-alg-agility.ad@ietf.org, housley@vigilsec.com, draft-iab-crypto-alg-agility.shepherd@ietf.org
Internet-Draft                                                R. Housley
Intended Status: Best Current Practice                    Vigil Security
Expires: 6 December 2015                                     4 June 2015

              Guidelines for Cryptographic Algorithm Agility
              and Selecting Mandatory-to-Implement Algorithms
                   <draft-iab-crypto-alg-agility-05.txt>

Abstract

   Many IETF protocols use cryptographic algorithms to provide
   confidentiality, integrity, authentication or digital signature.
   Communicating peers must support a common set of cryptographic
   algorithms for these mechanisms to work properly.  This memo provides
   guidelines to ensure that protocols have the ability to migrate from
   one mandatory-to-implement algorithm suite to another over time.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

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

Housley                                                         [Page 1]
Guidelines for Cryptographic Algorithm Agility                 June 2015

   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.

0.  TO DO

   Three comments have not been resolved yet ...

   (1) There is a minor organizational issue.  It looks like part of
   Section 3 could be merged with Section 2.  (I got initially confused
   by some ambiguous advice in 2.1 that was cleared up in 3.1).  Some of
   Section 3 belongs with the text in Section 4.  Specifically, 3.3 is
   really tied quite closely to 4.2, 4.3, and 4.4.

   (2) Nowhere does the document discuss directly the problem of long-
   term signatures in certificates hindering the dropping of weak
   signature algorithms and key lengths, even though this is an example
   that many people are familiar with.  If a CA signed a long-term cert
   with a signature using RSA-MD5, you can't easily drop MD5 support,
   you have to try to use it only in the exactly right places, which
   leads to errors.

   (3) The note in Section 3.2 on Performance belongs elsewhere, likely
   in the section on strength.

1.  Introduction

   Many IETF protocols use cryptographic algorithms to provide
   confidentiality, integrity, authentication, or digital signature.
   For interoperability, communicating peers must support a common set
   of cryptographic algorithms.  In most cases, a combination of
   compatible cryptographic algorithms will be used to provide the
   desired security services.  The set of cryptographic algorithms being
   used at a particular time is often referred to as a cryptographic
   algorithm suite or cipher suite.  In a protocol, algorithm
   identifiers might name a single cryptographic algorithm or a full
   suite of algorithms.

   Cryptographic algorithms age; they become weaker with time.  As new
   cryptanalysis techniques are developed and computing capabilities
   improve, the work factor to break a particular cryptographic
   algorithm will reduce or become more feasible for more attackers.

Housley                                                         [Page 2]
Guidelines for Cryptographic Algorithm Agility                 June 2015

   Algorithm agility is achieved when a protocol can easily migrate from
   one algorithm suite to another more desirable one, over time.  For
   the protocol implementer, this means that implementations should be
   modular to easily accommodate the insertion of new algorithms or
   suites of algorithms.  Ideally, implementations will also provide a
   way to measure when deployed implementations have shifted away from
   the old algorithms and to the better ones.  For the protocol
Show full document text