idnits 2.17.1 draft-iab-crypto-alg-agility-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 526 has weird spacing: '... of too man...' -- The document date (7 September 2015) is 3153 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended Status: Best Current Practice Vigil Security 4 Expires: 7 March 2016 7 September 2015 6 Guidelines for Cryptographic Algorithm Agility 7 and Selecting Mandatory-to-Implement Algorithms 8 10 Abstract 12 Many IETF protocols use cryptographic algorithms to provide 13 confidentiality, integrity, authentication or digital signature. 14 Communicating peers must support a common set of cryptographic 15 algorithms for these mechanisms to work properly. This memo provides 16 guidelines to ensure that protocols have the ability to migrate from 17 one mandatory-to-implement algorithm suite to another over time. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 Guidelines for Cryptographic Algorithm Agility September 2015 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Algorithm Agility Guidelines . . . . . . . . . . . . . . . . . 3 62 2.1. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 3 63 2.2. Mandatory-to-Implement Algorithms . . . . . . . . . . . . 4 64 2.2.1. Platform Specifications . . . . . . . . . . . . . . . 5 65 2.2.2. Cryptographic Key Size . . . . . . . . . . . . . . . . 5 66 2.2.3. Providing Notice of Expected Changes . . . . . . . . . 6 67 2.3. Transition from Weak Algorithms . . . . . . . . . . . . . 6 68 2.4. Algorithm Transition Mechanisms . . . . . . . . . . . . . 7 69 2.5. Cryptographic Key Management . . . . . . . . . . . . . . . 7 70 2.6. Preserving Interoperability . . . . . . . . . . . . . . . 8 71 2.7. Balance Security Strength . . . . . . . . . . . . . . . . 9 72 2.8. Balance Protocol Complexity . . . . . . . . . . . . . . . 9 73 2.9. Opportunistic Security . . . . . . . . . . . . . . . . . . 10 74 3. Cryptographic Algorithm Specifications . . . . . . . . . . . . 10 75 3.1. Choosing Mandatory-to-Implement Algorithms . . . . . . . . 10 76 3.2. Too Many Choices Can Be Harmful . . . . . . . . . . . . . 11 77 3.3. Picking One True Cipher Suite Can Be Harmful . . . . . . . 12 78 3.4. National Cipher Suites . . . . . . . . . . . . . . . . . . 13 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 6. Normative References . . . . . . . . . . . . . . . . . . . . . 16 82 7. Informative References . . . . . . . . . . . . . . . . . . . . 16 83 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 Many IETF protocols use cryptographic algorithms to provide 89 confidentiality, integrity, authentication, or digital signature. 90 For interoperability, communicating peers must support a common set 91 of cryptographic algorithms. In most cases, a combination of 92 compatible cryptographic algorithms will be used to provide the 93 desired security services. The set of cryptographic algorithms being 94 used at a particular time is often referred to as a cryptographic 96 Guidelines for Cryptographic Algorithm Agility September 2015 98 algorithm suite or cipher suite. In a protocol, algorithm 99 identifiers might name a single cryptographic algorithm or a full 100 suite of algorithms. 102 Cryptographic algorithms age; they become weaker with time. As new 103 cryptanalysis techniques are developed and computing capabilities 104 improve, the work required to break a particular cryptographic 105 algorithm will reduce, making an attack on the algorithm more 106 feasible for more attackers. While it is unknown how cryptoanalytic 107 attacks will evolve, it is certain that they will get better. It is 108 unknown how much better they will become, or when the advances will 109 happen. Protocol designers need to assume that advances in computing 110 power or advances in cryptoanalytic techniques will eventually make 111 any algorithm obsolete. For this reason, protocols need mechanisms 112 to migrate from one algorithm suite to another over time. 114 Algorithm agility is achieved when a protocol can easily migrate from 115 one algorithm suite to another more desirable one, over time. For 116 the protocol implementer, this means that implementations should be 117 modular to easily accommodate the insertion of new algorithms or 118 suites of algorithms. Ideally, implementations will also provide a 119 way to measure when deployed implementations have shifted away from 120 the old algorithms and to the better ones. For the protocol 121 designer, algorithm agility means that one or more algorithm or suite 122 identifiers must be supported, the set of mandatory-to-implement 123 algorithms will change over time, and an IANA registry of algorithm 124 identifiers will be needed. 126 Algorithm identifiers by themselves are not sufficient to ensure easy 127 migration. Action by people that maintain implementations and 128 operate services is needed to develop, deploy, and adjust 129 configuration settings to enable the new more desirable algorithms 130 and to deprecate or disable older, less desirable ones. For various 131 reasons, most notably interoperability concerns, experience has shown 132 that it has proven difficult for implementors and administrators to 133 remove or disable weak algorithms. Further, the inability of legacy 134 systems and resource-constrained devices to support new algorithms 135 adds to those concerns. As a result, people live with weaker 136 algorithms, sometimes seriously flawed ones, well after experts 137 recommend migration. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2. Algorithm Agility Guidelines 146 Guidelines for Cryptographic Algorithm Agility September 2015 148 These guidelines are for use by IETF working groups and protocol 149 authors for IETF protocols that make use of cryptographic algorithms. 150 Past attempts at algorithm agility have not been completely 151 successful, and this section provides some insights from those 152 experiences. 154 2.1. Algorithm Identifiers 156 IETF protocols that make use of cryptographic algorithms MUST support 157 one or more algorithms or suites. The protocol MUST include a 158 mechanism to identify the algorithm or suite that is being used. An 159 algorithm identifier might be explicitly carried in the protocol. 160 Alternatively, a management mechanism can be used to identify the 161 algorithm. For example, an entry in a key table that includes a key 162 value and an algorithm identifier might be sufficient. 164 If a protocol does not carry an algorithm identifier, then the 165 protocol version number or some other major change is needed to 166 transition from one algorithm to another. The inclusion of an 167 algorithm identifier is a minimal step toward cryptographic algorithm 168 agility. 170 Sometimes a combination of protocol version number and explicit 171 algorithm or suite identifiers is appropriate. For example, the TLS 172 [RFC5246] version number names the default key derivation function 173 and the cipher suite identifier names the rest of the needed 174 algorithms. 176 Some approaches carry one identifier for each algorithm that is used. 177 Other approaches carry one identifier for a full suite of algorithms. 178 Both approaches are used in IETF protocols. Designers are encouraged 179 to pick one of these approaches and use it consistently throughout 180 the protocol or family of protocols. Suite identifiers make it 181 easier for the protocol designer to ensure that the algorithm 182 selections are complete and compatible for future assignments. 183 However, suite identifiers inherently face a combinatoric explosion 184 as new algorithms are defined. Algorithm identifiers, on the other 185 hand, impose a burden on implementations by forcing a determination 186 at run-time regarding which algorithm combinations are acceptable. 188 Regardless of the approach used, protocols historically negotiate the 189 symmetric cipher and cipher mode together to ensure that they are 190 compatible. 192 In the IPsec protocol suite, IKEv2 [RFC7296] carries the algorithm 193 identifiers for AH [RFC4302] and ESP [RFC4303]. Such separation is a 194 completely fine design choice. In contrast, TLS [RFC5246] carries 195 cipher suite identifiers, which is also a completely fine design 197 Guidelines for Cryptographic Algorithm Agility September 2015 199 choice. 201 An IANA registry SHOULD be used for these algorithm or suite 202 identifiers. Once an algorithm identifier is added to the registry, 203 it should not be changed or removed. However, it is desirable to 204 mark a registry entry as deprecated when implementation is no longer 205 advisable. 207 2.2. Mandatory-to-Implement Algorithms 209 For secure interoperability, BCP 61 [RFC3365] recognizes that 210 communicating peers that use cryptographic mechanisms must support a 211 common set of strong cryptographic algorithms. For this reason, IETF 212 protocols that employ cryptography MUST specify one or more strong 213 mandatory-to-implement algorithms or suites. This does not require 214 all deployments to use this algorithm or suite, but it does require 215 that it be available to all deployments. 217 The IETF needs to be able to change the mandatory-to-implement 218 algorithms over time. It is highly desirable to make this change 219 without updating the base protocol specification. To achieve this 220 goal, it is RECOMMENDED that the base protocol specification includes 221 a reference to a companion algorithms document, allowing the update 222 of one document without necessarily requiring an update to the other. 223 This division also facilitates the advancement of the base protocol 224 specification on the standards maturity ladder even if the algorithm 225 document changes frequently. 227 The IETF SHOULD keep the set of mandatory-to-implement algorithms 228 small. To do so, the set of algorithms will necessarily change over 229 time, and the transition SHOULD happen before the algorithms in the 230 current set have weakened to the breaking point. 232 2.2.1. Platform Specifications 234 Note that mandatory-to-implement algorithms or suites are not 235 specified for protocols that are embedded in other protocols; in 236 these cases the system-level protocol specification identifies the 237 mandatory-to-implement algorithm or suite. For example, S/MIME 238 [RFC5751] makes use of the cryptographic message Syntax (CMS) 239 [RFC5652], and S/MIME specifies the mandatory-to-implement 240 algorithms, not CMS. This approach allows other protocols to make 241 use of CMS and make different mandatory-to-implement algorithm 242 choices. 244 2.2.2. Cryptographic Key Size 246 Some cryptographic algorithms are inherently tied to a specific key 248 Guidelines for Cryptographic Algorithm Agility September 2015 250 size, but others allow many different key sizes. Likewise, some 251 algorithms support parameters of different sizes, such as integrity 252 check values or nonces. The algorithm specification MUST identify 253 the specific key sizes and parameter sizes that are to be supported. 254 When more than one key size is available, expect the mandatory-to- 255 implement key size to increase over time. 257 Guidance on cryptographic key size for asymmetric keys can be found 258 in BCP 86 [RFC3766]. 260 Guidance on cryptographic key size for symmetric keys can be found in 261 BCP 195 [RFC7525]. 263 2.2.3. Providing Notice of Expected Changes 265 Fortunately, algorithm failures without warning are rare. More 266 often, algorithm transition is the result of age. For example, the 267 transition from DES to Triple-DES to AES took place over decades, 268 causing a shift in symmetric block cipher strength from 56 bits to 269 112 bits to 128 bits. Where possible, authors SHOULD provide notice 270 to implementers about expected algorithm transitions. One approach 271 that was first used in RFC 4307 [RFC4307] is to use SHOULD+, SHOULD-, 272 and MUST- in the specification of algorithms. 274 SHOULD+ This term means the same as SHOULD. However, it is 275 likely that an algorithm marked as SHOULD+ will be 276 promoted to a MUST in the future. 278 SHOULD- This term means the same as SHOULD. However, it is 279 likely that an algorithm marked as SHOULD- will be 280 deprecated to a MAY or worse in the future. 282 MUST- This term means the same as MUST. However, it is 283 expected that an algorithm marked as MUST- will be 284 downgraded in the future. Although the status of the 285 algorithm will be determined at a later time, it is 286 reasonable to expect that a the status of a MUST- 287 algorithm will remain at least a SHOULD or a SHOULD-. 289 2.3. Transition from Weak Algorithms 291 Transition from an old algorithm that is found to be weak can be 292 tricky. It is of course straightforward to specify the use of a new, 293 better algorithm. And then, when the new algorithm is widely 294 deployed, the old algorithm ought no longer be used. However, 295 knowledge about the implementation and deployment of the new 296 algorithm will always be imperfect, so one cannot be completely 297 assured of interoperability with the new algorithm. 299 Guidelines for Cryptographic Algorithm Agility September 2015 301 Algorithm transition is naturally facilitated as part of an algorithm 302 selection or negotiation mechanism. Protocols traditionally select 303 the best algorithm or suite that is supported by all communicating 304 peers and acceptable by their policies. In addition, a mechanism is 305 needed to determine whether the new algorithm has been deployed. For 306 example, SMIMECapabilities [RFC5751] allows S/MIME mail user agents 307 to share the list of algorithms that they are willing to use in 308 preference order. For another example, the DNSSEC EDNS0 option 309 [RFC6975] measures the acceptance and use of new digital signing 310 algorithms. 312 In the Resource Public Key Infrastructure (RPKI), a globally- 313 recognized digital signature is needed. BCP 182 [RFC6916] provides 314 an approach to transition where a second signature algorithm is 315 introduced and then the original one is phased out. 317 In the worst case, the old algorithm may be found to be tragically 318 flawed, permitting a casual attacker to download a simple script to 319 break it. Sadly, this has happened when a secure algorithm is used 320 incorrectly or used with poor key management, resulting in a weak 321 cryptographic algorithm suite. In such situations, the protection 322 offered by the algorithm is severely compromised, perhaps to the 323 point that one wants to stop using the weak suite altogether, 324 rejecting offers to use the weak suite well before the new suite is 325 widely deployed. 327 In any case, there comes a point in time where one refuses to use the 328 old, weak algorithm or suite. This can happen on a flag day, or each 329 installation can select a date on their own. 331 2.4. Algorithm Transition Mechanisms 333 Cryptographic algorithm selection or negotiation SHOULD be integrity 334 protected. If selection is not integrity protected, then the 335 protocol will be subject to a downgrade attack. Without integrity 336 protection of algorithm or suite selection, the attempt to transition 337 to a new algorithm or suite may introduce new opportunities for 338 downgrade attacks. 340 Transition mechanisms need to consider the algorithm that is used to 341 provide integrity protection for algorithm negotiation itself. 343 If a protocol specifies a single mandatory-to-implement integrity 344 algorithm, eventually that algorithm will be found to be weak. 346 Extra care is needed when a mandatory-to-implement algorithm is used 347 to provide integrity protection for the negotiation of other 348 cryptographic algorithms. In this situation, a flaw in the 350 Guidelines for Cryptographic Algorithm Agility September 2015 352 mandatory-to-implement algorithm may allow an attacker to influence 353 the choices of the other algorithms. 355 2.5. Cryptographic Key Establishment 357 Traditionally, protocol designers have avoided more than one approach 358 to exchanges that establish cryptographic keys because it makes the 359 security analysis of the overall protocol more difficult. When 360 frameworks such as EAP [RFC3748] and SASL [RFC4422] are employed, key 361 establishment is very flexible, often hiding many of the details from 362 the application. This results in protocols that support multiple key 363 establishment approaches. In fact, the key establishment approach 364 itself is negotiable, which creates a design challenge to protect the 365 negotiation of the key establishment approach before it is used to 366 produce cryptographic keys. 368 Protocols can negotiate a key establishment approach, derive an 369 initial cryptographic key, and then authenticate the negotiation. 370 However, if the authentication fails, the only recourse is to start 371 the negotiation over from the beginning. 373 Some environments will restrict the key establishment approaches by 374 policy. Such policies tend to improve interoperability within a 375 particular environment, but they cause problems for individuals that 376 need to work in multiple incompatible environments. 378 2.6. Preserving Interoperability 380 Cryptographic algorithm deprecation is very difficult. People do not 381 like to introduce interoperability problems, even to preserve 382 security. As a result, flawed algorithms are supported for far too 383 long. The impact of legacy software and long support tails on 384 security can be reduced by making it easy to transition from old 385 algorithms and suites to new ones. Social pressure is often needed 386 to cause the transition to happen. 388 Implementers have been reluctant to remove deprecated algorithms or 389 suites from server software, and server administrators have been 390 reluctant to disable them over concerns that some party will no 391 longer have the ability to connect to their server. Implementers and 392 administrators want to improve security by using the best supported 393 algorithms, but their actions are tempered by the desire to preserve 394 connectivity. Recently, some browser vendors have started to provide 395 visual warnings when a deprecated algorithm or suite is used. These 396 visual warnings provide a new incentive to transition away from 397 deprecated algorithms and suites, prompting customers to ask for 398 improved security. 400 Guidelines for Cryptographic Algorithm Agility September 2015 402 Transition in Internet infrastructure is particularly difficult. The 403 digital signature on the certificate for an intermediate 404 certification authority (CA) [RFC5280] is often expected to last 405 decades, which hinders the transition away from a weak signature 406 algorithm or short key length. Once a long-lived certificate is 407 issued with a particular signature algorithm, that algorithm will be 408 used by many relying parties, and none of them can stop supporting it 409 without invalidating all of the subordinate certificates. In a 410 hierarchical system, many subordinate certificates could be impacted 411 by the decision to drop support for a weak signature algorithm or an 412 associated hash function. 414 Organizations that have a significant influence can assist by 415 coordinating the demise of an algorithm suite, making the transition 416 easier for their own users as well as others. 418 2.7. Balance Security Strength 420 When selecting or negotiating a suite of cryptographic algorithms, 421 the strength of each algorithm SHOULD be considered. The algorithms 422 in a suite SHOULD be roughly equal by providing comparable best known 423 attack work factors. However, the security service provided by each 424 algorithm in a particular context needs to be considered when making 425 the selection. Algorithm strength needs to be considered at the time 426 a protocol is designed. It also needs to be considered at the time a 427 protocol implementation is deployed and configured. Advice from from 428 experts is useful, but in reality, such advice is often unavailable 429 to system administrators that are deploying a protocol 430 implementation. For this reason, protocol designers SHOULD provide 431 clear guidance to implementors, leading to balanced options being 432 available at the time of deployment. 434 Performance is always a factor is selecting cryptographic algorithms. 435 Performance and security need to be balanced. Some algorithms offer 436 flexibility in their strength by adjusting the key size, number of 437 rounds, authentication tag size, prime group size, and so on. For 438 example, TLS cipher suites include Diffie-Hellman or RSA without 439 specifying a particular public key length. If the algorithm 440 identifier or suite identifier named a particular public key length, 441 migration to longer ones would be more difficult. On the other hand, 442 inclusion of a public key length would make it easier to migrate away 443 from short ones when computational resources available to attacker 444 dictate the need to do so. The flexibility on asymmetric key length 445 has led to interoperability problems, and to avoid these problems in 446 the future any aspect of the algorithm not specified by the algorithm 447 identifiers need to be negotiated, including key size and parameters. 449 In CMS [RFC5652], a previously distributed symmetric key-encryption 451 Guidelines for Cryptographic Algorithm Agility September 2015 453 key can be used to encrypt a content-encryption key, which in turn is 454 used to encrypt the content. The key-encryption and content- 455 encryption algorithms are often different. If, for example, a 456 message content is encrypted with 128-bit AES key and the content- 457 encryption key is wrapped with a 256-bit AES key, then at most 128 458 bits of protection is provided. In this situation, the algorithm and 459 key size selections should ensure that the key encryption is at least 460 as strong as the content encryption. In general, wrapping one key 461 with another key of a different size yields the security strength of 462 the shorter key. 464 2.8. Balance Protocol Complexity 466 Protocol designs need to anticipate changes in the supported 467 cryptographic algorithm set over time. There are a number of ways to 468 enable the transition, and Section 3 discusses some of the related 469 issues. 471 Keep implementations as simple as possible. Complex protocol 472 negotiation provides opportunities for attack, such as downgrade 473 attacks. Support for many algorithm alternatives is also harmful. 474 Both of these can lead to portions of the implementation that are 475 rarely used, increasing the opportunity for undiscovered exploitable 476 implementation bugs. 478 2.9. Opportunistic Security 480 Despite the guidance in Section 2.4, opportunistic security [RFC7435] 481 also deserves consideration, especially at the time a protocol 482 implementation is deployed and configured. Using algorithms that are 483 weak against advanced attackers but sufficient against others is one 484 way to make pervasive surveillance significantly more difficult. As 485 a result, algorithms that would not be acceptable in many negotiated 486 situations are acceptable for opportunistic security when legacy 487 systems are in use for unauthenticated encrypted sessions as 488 discussed in Section 3 of [RFC7435] as long as their use does not 489 facilitate downgrade attacks. Similarly, weaker algorithms and 490 shorter key sizes are also acceptable for opportunistic security with 491 the same constraints. That said, the use of strong algorithms is 492 always preferable. 494 3. Cryptographic Algorithm Specifications 496 There are tradeoffs between the number of cryptographic algorithms 497 that are supported and the time to deploy a new algorithm. This 498 section provides some of the insights about the tradeoff faced by 499 protocol designers. 501 Guidelines for Cryptographic Algorithm Agility September 2015 503 Ideally, two independent sets of mandatory-to-implement algorithms 504 will be specified, allowing for a primary suite and a secondary 505 suite. This approach ensures that the secondary suite is widely 506 deployed if a flaw is found in the primary one. 508 3.1. Choosing Mandatory-to-Implement Algorithms 510 It may seem as if the ability to use an algorithm of one's own 511 choosing is very desirable; however, the selection is often better 512 left to experts. When there are choices, end-users might select 513 between configuration profiles that have been defined by experts. 514 Further, experts need not specify each and every cryptographic 515 algorithm alternative. Specifying all possible choices will not lead 516 to them all being available in every implementation. Mandatory-to- 517 implement algorithms MUST have a stable public specification and 518 public documentation that has been well studied, giving rise to 519 significant confidence. The IETF has always had a preference for 520 unencumbered algorithms. There are significant benefits in selecting 521 algorithms and suites that are widely deployed. The selected 522 algorithms need to be resistant to side-channel attacks and also meet 523 the performance, power, and code size requirements on a wide variety 524 of platforms. In addition, inclusion of too many alternatives may 525 add complexity to algorithm selection or negotiation. Specification 526 of too many alternatives will likely hamper interoperability and may 527 hamper security as well. When specifying new algorithms or suites, 528 protocol designers would be prudent to consider whether existing ones 529 can be deprecated. 531 There is significant benefit in selecting the same algorithms and 532 suites for different protocols. Using the same algorithms can 533 simplify implementation when more than one of the protocols is used 534 in the same device or system. 536 Sometimes more than one mandatory-to-implement algorithm is needed to 537 increase the likelihood of interoperability among a diverse 538 population. For example, authenticated encryption is provided by 539 AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are 540 considered to be secure. AES-CCM is available in hardware used by 541 many small devices, and AES-GCM is parallelizable and well suited 542 high-speed devices. Therefore an application needing authenticated 543 encryption might specify one of these algorithms or both of these 544 algorithms, depending on the population. 546 3.2. Too Many Choices Can Be Harmful 548 It is fairly easy to specify the use of any arbitrary cryptographic 549 algorithm, and once the specification is available, the algorithm 550 gets implemented and deployed. Some people say that the freedom to 552 Guidelines for Cryptographic Algorithm Agility September 2015 554 specify algorithms independently from the rest of the protocol has 555 lead to the specification of too many cryptographic algorithms. Once 556 deployed, even with moderate uptake, it is quite difficult to remove 557 algorithms because interoperability with some party will be impacted. 558 As a result, weaker ciphers stick around far too long. Sometimes 559 implementors are forced to maintain cryptographic algorithm 560 implementations well beyond their useful lifetime. 562 In order to manage the proliferation of algorithm choices and provide 563 an expectation of interoperability, many protocols specify mandatory- 564 to-implement algorithms or suites. All implementors are expected to 565 support the mandatory-to-implement cryptographic algorithm, and they 566 can include any others algorithms that they desire. The mandatory- 567 to-implement algorithms are chosen to be highly secure and follow the 568 guidance in RFC 1984 [RFC1984]. Of course, many other factors, 569 including intellectual property rights, have an impact on the 570 cryptographic algorithms that are selected by the community. 571 Generally, the mandatory-to-implement algorithms ought to be 572 preferred, and the other algorithms ought to be selected only in 573 special situations. However, it can be very difficult for a skilled 574 system administrator to determine the proper configuration to achieve 575 these preferences. 577 In some cases, more than one mandatory-to-implement cryptographic 578 algorithm has been specified. This is intended to ensure that at 579 least one secure cryptographic algorithm will be available, even if 580 other mandatory-to-implement algorithms are broken. To achieve this 581 goal, the selected algorithms must be diverse, so that a 582 cryptoanalytic advance against one of the algorithms does not also 583 impact the other selected algorithms. The idea is to have an 584 implemented and deployed algorithm as a fallback. However, all of 585 the selected algorithms need to be routinely exercised to ensure 586 quality implementation. This is not always easy to do, especially if 587 the various selected algorithms require different credentials. 588 Obtaining multiple credentials for the same installation is an 589 unacceptable burden on system administrators. Also, the manner by 590 which system administrators are advised to switch algorithms or 591 suites is at best ad hoc, and at worst entirely absent. 593 3.3. Picking One True Cipher Suite Can Be Harmful 595 In the past, protocol designers have chosen one cryptographic 596 algorithm or suite, and then tied many protocol details to that 597 selection. Plan for algorithm transition, either because a mistake 598 is made in the initial selection or because the protocol is 599 successfully used for a long time and the algorithm becomes weak with 600 age. Either way, the design should enable transition. 602 Guidelines for Cryptographic Algorithm Agility September 2015 604 Protocol designers are sometimes misled by the simplicity that 605 results from selecting one true algorithm or suite. Since algorithms 606 age, the selection cannot be stable forever. Even the most simple 607 protocol needs a version number to signal which algorithm is being 608 used. This approach has at least two desirable consequences. First, 609 the protocol is simpler because there is no need for algorithm 610 negotiation. Second, system administrators do not need to make any 611 algorithm-related configuration decisions. However, the only way to 612 respond to news that the an algorithm that is part of the one true 613 cipher suite has been broken is to update the protocol specification 614 to the next version, implement the new specification, and then get it 615 deployed. 617 The first IEEE 802.11 [WiFi] specification included Wired Equivalent 618 Privacy (WEP) as the only encryption technique. Many of the protocol 619 details were driven by the selected algorithm. WEP was found to be 620 quite weak [WEP], and a very large effort was needed to specify, 621 implement, and deploy the alternative encryption techniques. This 622 effort was made even harder by the protocol design choices that were 623 tied to the initial algorithm selection and the desire for backward 624 compatibility. 626 Experience with the transition from SHA-1 to SHA-256 indicates that 627 the time from protocol specification to widespread use takes more 628 than five years. In this case, the protocol specifications and 629 implementation were straightforward and fairly prompt. In many 630 software products, the new algorithm was not considered an update to 631 existing release, so the roll-out of the next release, subsequent 632 deployment, and finally adjustment of the configuration by system 633 administrators took many years. In many consumer hardware products, 634 firmware to implement the new algorithm were difficult to locate and 635 install, or the were simply not available. Further, infrastructure 636 providers were unwilling to make the transition until all of their 637 potential clients were able to use the new algorithm. 639 3.4. National Cipher Suites 641 Some nations specify cryptographic algorithms, and then require their 642 use through legislation or regulations. These algorithms may not 643 have wide public review, and they can have limited reach of 644 deployments. Yet, the legislative or regulatory mandate creates a 645 captive market. As a result, the use of such algorithms will get 646 specified, implemented, and deployed. The default server or 647 responder configuration SHOULD disable such algorithms; in this way, 648 explicit action by the system administrator is needed to enable them 649 where they are actually required. For tiny devices with no user 650 interface, an administrator action may only be possible at the time 651 the device is purchased. 653 Guidelines for Cryptographic Algorithm Agility September 2015 655 National algorithms can force an implementer to produce several 656 incompatible product releases for a different countries or regions, 657 which has significantly greater cost over development of a product 658 using a globally-acceptable algorithm. This situation could be even 659 worse if the various national algorithms impose different 660 requirements on the protocol, its key management, or its use of 661 random values. 663 4. Security Considerations 665 This document provides guidance to working groups and protocol 666 designers. The security of the Internet is improved when broken or 667 weak cryptographic algorithms can be easily replaced with strong 668 ones. 670 From a software development and maintenance perspective, 671 cryptographic algorithms can often be added and removed without 672 making changes to surrounding data structures, protocol parsing 673 routines, or state machines. This approach separates the 674 cryptographic algorithm implementation from the rest of the code, 675 which makes it easier to tackle special security concerns such as key 676 exposure and constant-time execution. 678 Sometimes application layer protocols can make use of transport layer 679 security protocols, such as TLS [RFC5246] or DTLS [RFC6347]. This 680 insulates the application layer protocol from the details of 681 cryptography, but it is likely to still be necessary to handle the 682 transition from unprotected traffic to protected traffic in the 683 application layer protocol. In addition, the application layer 684 protocol may need to handle the downgrade from encrypted 685 communication to plaintext communication. 687 Hardware offers challenges in the transition of algorithms, for both 688 tiny devices and very high-end data center equipment. Many tiny 689 devices do not include the ability to update the firmware at all. 690 Even if the firmware can be updated, tiny devices are often deployed 691 in places that make it very inconvenient to do so. High-end data 692 center equipment may use special-purpose chips to achieve very high 693 performance, which means that board-level replacement may be needed 694 to change the algorithm. Cost and down-time are both factors in such 695 an upgrade. 697 In most cases, the cryptographic algorithm remains strong, but an 698 attack is found against the way that the strong algorithm is used in 699 a particular protocol. In these cases, a protocol change will 700 probably be needed. For example, the order of cryptographic 701 operations in the TLS protocol has evolved as various attacks have 702 been discovered. Originally, TLS performed encryption after 704 Guidelines for Cryptographic Algorithm Agility September 2015 706 computation of the message authentication code (MAC). This order of 707 operations is called MAC-then-encrypt, which actually involves MAC 708 computation, padding, and then encryption. This is no longer 709 considered secure [BN][K]. As a result, a mechanism was specified to 710 use encrypt-then-MAC instead [RFC7366]. Future versions of TLS are 711 expected to use exclusively authenticated encryption algorithms 712 [RFC5116], which should resolve the ordering discussion altogether. 713 After discovery of such attacks, updating the cryptographic 714 algorithms is not likely to be sufficient to thwart the new attack. 715 It may necessary to make significant changes to the protocol. 717 Some protocols are used to protect stored data. For example, S/MIME 718 [RFC5751] can protect a message kept in a mailbox. To recover the 719 protected stored data, protocol implementations need to support older 720 algorithms, even when they no longer use the older algorithms for the 721 protection of new stored data. 723 Support for too many algorithms can lead to implementation 724 vulnerabilities. When many algorithms are supported, some of them 725 will be rarely used. Any code that is rarely used can contain 726 undetected bugs, and algorithm implementations are no different. 727 Measurements SHOULD be used to determine whether implemented 728 algorithms are actually being used, and if they are not, future 729 releases should remove them. In addition, unused algorithms or 730 suites SHOULD be marked as deprecated in the IANA registry. In 731 short, eliminate the cruft. 733 Section 2.3 talks about algorithm transition without considering any 734 other aspects of the protocol design. In practice, there are 735 dependencies between the cryptographic algorithm and other aspects of 736 the protocol. For example, the BEAST attack [BEAST] against TLS 737 [RFC5246] caused many sites to turn off modern cryptographic 738 algorithms in favor of older and clearly weaker algorithms. 740 Mechanisms for timely update of devices are needed to deploy a 741 replacement algorithm or suite. It takes a long time to specify, 742 implement, and deploy a replacement, therefore the transition process 743 needs to begin when practically exploitable flaws become known. The 744 update processes on some devices involve certification, which further 745 increases the time to deploy a replacement. For example, devices 746 that are part of health or safety systems often require certification 747 before deployment. Embedded systems and SCADA systems often have 748 upgrade cycles stretching over many years, leading to similar time to 749 deployment issues. Prompt action is needed if a replacement has any 750 hope of being deployed before exploitation techniques become widely 751 available exploits. 753 5. IANA Considerations 754 Guidelines for Cryptographic Algorithm Agility September 2015 756 This document does not establish any new IANA registries, nor does it 757 add any entries to existing registries. 759 This document does RECOMMEND a convention for new registries for 760 cryptographic algorithm or suite identifiers. Once an algorithm or 761 suite identifier is added to the registry, it SHOULD NOT be changed 762 or removed. However, it is desirable to include a means of marking a 763 registry entry as deprecated when implementation is no longer 764 advisable. 766 6. Normative References 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 772 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 773 April 2004. 775 7. Informative References 777 [BEAST] http://en.wikipedia.org/wiki/ 778 Transport_Layer_Security#BEAST_attack. 780 [BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: 781 Relations among notions and analysis of the generic 782 composition paradigm", Proceedings of AsiaCrypt '00, 783 Springer-Verlag LNCS No. 1976, p. 531, December 2000. 785 [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of 786 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 787 Special Publication 800-30D, November 2007. 789 [K] Krawczyk, H., "The Order of Encryption and Authentication 790 for Protecting Communications (or: How Secure Is SSL?)", 791 Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, 792 p. 310, August 2001. 794 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 795 Technology and the Internet", RFC 1984, August 1996. 797 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 798 Engineering Task Force Standard Protocols", BCP 61, RFC 799 3365, August 2002. 801 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 802 CBC-MAC (CCM)", RFC 3610, September 2003. 804 Guidelines for Cryptographic Algorithm Agility September 2015 806 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 807 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 808 3748, June 2004. 810 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 811 2005. 813 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 814 RFC 4303, December 2005. 816 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 817 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 818 December 2005. 820 [RFC4422] Melnikov, A., and K. Zeilenga, "Simple Authentication and 821 Security Layer (SASL)", RFC 4422, June 2006. 823 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 824 Encryption", RFC 5116, January 2008. 826 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 827 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 829 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 830 Housley, R., and W. Polk, "Internet X.509 Public Key 831 Infrastructure Certificate and Certificate Revocation List 832 (CRL) Profile", RFC 5280, May 2008. 834 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 835 RFC 5652, September 2009. 837 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 838 Mail Extensions (S/MIME) Version 3.2 Message 839 Specification", RFC 5751, January 2010. 841 [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 842 Security Version 1.2", RFC 6347, January 2012. 844 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 845 Procedure for the Resource Public Key Infrastructure 846 (RPKI)", BCP 182, RFC 6916, April 2013. 848 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm 849 Understanding in DNS Security Extensions (DNSSEC)", 850 RFC 6975, July 2013. 852 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 853 Kivinen, "Internet Key Exchange Protocol Version 2 855 Guidelines for Cryptographic Algorithm Agility September 2015 857 (IKEv2)", STD 79, RFC 7296, October 2014. 859 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security 860 (TLS) and Datagram Transport Layer Security (DTLS)", 861 RFC 7366, September 2014. 863 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most 864 of the Time", RFC 7435, December 2014. 866 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations 867 for Secure Use of Transport Layer Security (TLS) and 868 Datagram Transport Layer Security (DTLS)", RFC 7525, 869 BCP 195, May 2015. 871 [WEP] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy 873 [WiFi] IEEE , "Wireless LAN Medium Access Control (MAC) And 874 Physical Layer (PHY) Specifications, IEEE Std 802.11-1997, 875 1997. 877 Acknowledgements 879 Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon 880 Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, 881 Tony Finch, Ian Grigg, Peter Gutmann, Wes Hardaker, Joe Hildebrand, 882 Paul Hoffman, Phillip Hallam-Baker, Christian Huitema, Leif 883 Johansson, Suresh Krishnan, Watson Ladd, Paul Lambert, Ben Laurie, 884 Eliot Lear, Nikos Mavrogiannopoulos, Kathleen Moriarty, Yoav Nir, 885 Kenny Paterson, Rich Salz, Wendy Seltzer, Joel Sing, Rene Struik, 886 Kristof Teichel, Martin Thompson, Jeffrey Walton, Nico Williams, and 887 Peter Yee for their review and insightful comments. While some of 888 these people do not agree with some aspects of this document, the 889 discussion that resulted for their comments has certainly resulted in 890 a better document. 892 Author's Address 894 Russ Housley 895 Vigil Security, LLC 896 918 Spring Knoll Drive 897 Herndon, VA 20170 898 USA 899 EMail: housley@vigilsec.com