idnits 2.17.1 draft-iab-crypto-alg-agility-07.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 -- The document date (17 August 2015) is 3167 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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: 18 February 2016 17 August 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 August 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 1. Introduction 59 Many IETF protocols use cryptographic algorithms to provide 60 confidentiality, integrity, authentication, or digital signature. 61 For interoperability, communicating peers must support a common set 62 of cryptographic algorithms. In most cases, a combination of 63 compatible cryptographic algorithms will be used to provide the 64 desired security services. The set of cryptographic algorithms being 65 used at a particular time is often referred to as a cryptographic 66 algorithm suite or cipher suite. In a protocol, algorithm 67 identifiers might name a single cryptographic algorithm or a full 68 suite of algorithms. 70 Cryptographic algorithms age; they become weaker with time. As new 71 cryptanalysis techniques are developed and computing capabilities 72 improve, the work factor to break a particular cryptographic 73 algorithm will reduce, becoming more feasible for more attackers. 74 Advances in computing power available to the attacker will eventually 75 make any algorithm obsolete. For this reason, protocols need 76 mechanisms to migrate from one algorithm suite to another over time. 78 Algorithm agility is achieved when a protocol can easily migrate from 79 one algorithm suite to another more desirable one, over time. For 80 the protocol implementer, this means that implementations should be 81 modular to easily accommodate the insertion of new algorithms or 82 suites of algorithms. Ideally, implementations will also provide a 83 way to measure when deployed implementations have shifted away from 84 the old algorithms and to the better ones. For the protocol 85 designer, algorithm agility means that one or more algorithm 86 identifier must be supported, the set of mandatory-to-implement 87 algorithms will change over time, and an IANA registry of algorithm 88 identifiers will be needed. 90 Algorithm identifiers by themselves are not sufficient to ensure easy 91 migration. Action by people that maintain implementations and 92 operate services is needed to develop, deploy, and adjust 93 configuration settings to enable the new more desirable algorithms 94 and to deprecate or disable older, less desirable ones. For various 96 Guidelines for Cryptographic Algorithm Agility August 2015 98 reasons, most notably interoperability concerns, experience has shown 99 that it has proven difficult for implementors and administrators to 100 remove or disable weak algorithms. Further, the inability of legacy 101 systems and resource-constrained devices to support new algorithms 102 adds to those concerns. As a result, people live with weaker 103 algorithms, sometimes seriously flawed ones, well after experts 104 recommend migration. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Algorithm Agility Guidelines 114 These guidelines are for use by IETF working groups and protocol 115 authors for IETF protocols that make use of cryptographic algorithms. 116 Past attempts at algorithm agility have not been completely 117 successful, and this section provides some insights from those 118 experiences. 120 2.1. Algorithm Identifiers 122 IETF protocols that make use of cryptographic algorithms MUST support 123 one or more algorithm or suite identifier. The identifier might be 124 explicitly carried in the protocol. Alternatively, it can configured 125 by a management mechanism. For example, an entry in a key table that 126 includes a key value and an algorithm identifier might be sufficient. 128 If a protocol does not carry an algorithm identifier, then the 129 protocol version number or some other major change is needed to 130 transition from one algorithm to another. The inclusion of an 131 algorithm identifier is a minimal step toward cryptographic algorithm 132 agility. 134 Sometimes a combination of protocol version number and explicit 135 algorithm or suite identifiers is appropriate. For example, the TLS 136 [RFC5246] version number names the default key derivation function 137 and the cipher suite identifier names the rest of the needed 138 algorithms. 140 Some approaches carry one identifier for each algorithm that is used. 141 Other approaches carry one identifier for a full suite of algorithms. 142 Both approaches are used in IETF protocols. Designers are encouraged 143 to pick one of these approaches and use it consistently throughout 144 the protocol or family of protocols. Suite identifiers make it 145 easier for the protocol designer to ensure that the algorithm 147 Guidelines for Cryptographic Algorithm Agility August 2015 149 selections are complete and compatible for future assignments. 150 However, suite identifiers inherently face a combinatoric explosion 151 as new algorithms are defined. Algorithm identifiers, on the other 152 hand, impose a burden on implementations by forcing a determination 153 at run-time regarding which algorithm combinations are acceptable. 155 Regardless of the approach used, protocols historically negotiate the 156 symmetric cipher and cipher mode together to ensure that they are 157 completely compatible. 159 In the IPsec protocol suite, IKEv2 [RFC7296] carries the algorithm 160 identifiers for AH [RFC4302] and ESP [RFC4303]. Such separation is a 161 completely fine design choice. In contrast, TLS [RFC5246] carries 162 cipher suite identifiers, which is also a completely fine design 163 choice. 165 An IANA registry SHOULD be used for these algorithm or suite 166 identifiers. Once an algorithm identifier is added to the registry, 167 it should not be changed or removed. However, it is desirable to 168 mark a registry entry as deprecated when implementation is no longer 169 advisable. 171 2.2. Mandatory-to-Implement Algorithms 173 For secure interoperability, BCP 61 [RFC3365] recognizes that 174 communicating peers that use cryptographic mechanisms must support a 175 common set of strong cryptographic algorithms. For this reason, the 176 protocol MUST specify one or more strong mandatory-to-implement 177 algorithm or suite. This does not require all deployments to use 178 this algorithm or suite, but it does require that it be available to 179 all deployments. 181 The IETF needs to be able to change the mandatory-to-implement 182 algorithms over time. It is highly desirable to make this change 183 without updating the base protocol specification. To achieve this 184 goal, the base protocol specification includes a reference to a 185 companion algorithms document, allowing the update of one document 186 without necessarily requiring an update to the other. This division 187 also facilitates the advancement of the base protocol specification 188 on the standards maturity ladder even if the algorithm document 189 changes frequently. 191 The IETF SHOULD keep the set of mandatory-to-implement algorithms 192 small. To do so, the set of algorithms will necessarily change over 193 time, and the transition SHOULD happen before the algorithms in the 194 current set have weakened to the breaking point. 196 Guidelines for Cryptographic Algorithm Agility August 2015 198 2.2.1. Platform Specifications 200 Note that mandatory-to-implement algorithms or suites are not 201 specified for protocols that are embedded in other protocols; in 202 these cases the system-level protocol specification identifies the 203 mandatory-to-implement algorithm or suite. For example, S/MIME 204 [RFC5751] makes use of the cryptographic message Syntax (CMS) 205 [RFC5652], and S/MIME specifies the mandatory-to-implement 206 algorithms, not CMS. This approach allows other protocols can make 207 use of CMS and make different mandatory-to-implement algorithm 208 choices. 210 2.2.2. Cryptographic Key Size 212 Some cryptographic algorithms are inherently tied to a specific key 213 size, but others allow many different key sizes. Likewise, some 214 algorithms support parameters of different sizes, such as integrity 215 check values or nonces. The algorithm specification MUST identify 216 the specific key sizes and parameter sizes that are to be supported. 217 When more than one key size is available, expect the mandatory-to- 218 implement key size to increase over time. 220 Guidance on cryptographic key size for asymmetric keys can be found 221 in BCP 86 [RFC3766]. 223 Guidance on cryptographic key size for symmetric keys can be found in 224 BCP 195 [RFC7525]. 226 2.2.3. Providing Notice of Expected Changes 228 Fortunately, catastrophic algorithm failures without warning are 229 rare. More often, algorithm transition is the result of age. For 230 example, the transition from DES to Triple-DES to AES took place over 231 decades, causing a shift in symmetric block cipher strength from 56 232 bits to 112 bits to 128 bits. Where possible, authors SHOULD provide 233 notice to implementers about expected algorithm transitions. One 234 approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+, 235 SHOULD-, and MUST- in the specification of algorithms. 237 SHOULD+ This term means the same as SHOULD. However, it is 238 likely that an algorithm marked as SHOULD+ will be 239 promoted to a MUST in the future. 241 SHOULD- This term means the same as SHOULD. However, it is 242 likely that an algorithm marked as SHOULD- will be 243 deprecated to a MAY or worse in the future. 245 Guidelines for Cryptographic Algorithm Agility August 2015 247 MUST- This term means the same as MUST. However, it is 248 expected that an algorithm marked as MUST- will be 249 downgraded in the future. Although the status of the 250 algorithm will be determined at a later time, it is 251 reasonable to expect that a the status of a MUST- 252 algorithm will remain at least a SHOULD or a SHOULD-. 254 2.3. Transition from Weak Algorithms 256 Transition from an old algorithm that is found to be weak can be 257 tricky. It is of course straightforward to specify the use of a new, 258 better algorithm. And then, when the new algorithm is widely 259 deployed, the old algorithm ought no longer be used. However, 260 knowledge about the implementation and deployment of the new 261 algorithm will always be imperfect, so one cannot be completely 262 assured of interoperability with the new algorithm. 264 Algorithm transition is naturally facilitated as part of an algorithm 265 selection or negotiation mechanism. Protocols traditionally select 266 the best algorithm or suite that is supported by all communicating 267 peers and acceptable by their policies. In addition, a mechanism is 268 needed to determine whether the new algorithm has been deployed. For 269 example, SMIMECapabilities [RFC5751] allows S/MIME mail user agents 270 to share the list of algorithms that they are willing to use in 271 preference order. For another example, the DNSSEC EDNS0 option 272 [RFC6975] measures the acceptance and use of new digital signing 273 algorithms. 275 In the Resource Public Key Infrastructure (RPKI), a globally- 276 recognized digital signature is needed. BCP 182 [RFC6916] provides 277 an approach to transition where a second signature algorithm is 278 introduced and then the original one is phased out. 280 In the worst case, the old algorithm may be found to be tragically 281 flawed, permitting a casual attacker to download a simple script to 282 break it. Sadly, this has happened when a secure algorithm is used 283 incorrectly or used with poor key management, resulting in a weak 284 cryptographic algorithm suite. In such situations, the protection 285 offered by the algorithm is severely compromised, perhaps to the 286 point that one wants to stop using the weak suite altogether, 287 rejecting offers to use the weak suite well before the new suite is 288 widely deployed. 290 In any case, there comes a point in time where one refuses to use the 291 old, weak algorithm or suite. This can happen on a flag day, or each 292 installation can select a date on their own. 294 Guidelines for Cryptographic Algorithm Agility August 2015 296 2.4. Algorithm Transition Mechanisms 298 Cryptographic algorithm selection or negotiation SHOULD be integrity 299 protected. If selection is not integrity protected, then the 300 protocol will be subject to a downgrade attack. Without integrity 301 protection of algorithm or suite selection, the attempt to transition 302 to a new algorithm or suite may introduce new opportunities for 303 downgrade attack. 305 Transition mechanisms SHOULD consider the algorithm that is used to 306 provide integrity protection for algorithm negotiation itself. 308 If a protocol specifies a single mandatory-to-implement integrity 309 algorithm, eventually that algorithm will be found to be weak. 311 Extra care is needed when a mandatory-to-implement algorithm is used 312 to provide integrity protection for the negotiation of other 313 cryptographic algorithms. In this situation, a flaw in the 314 mandatory-to-implement algorithm may allow an attacker to influence 315 the choices of the other algorithms. 317 2.5. Cryptographic Key Management 319 Traditionally, protocol designers have avoided more than one approach 320 to key management because it makes the security analysis of the 321 overall protocol more difficult. When frameworks such as EAP and 322 GSSAPI are employed, the key management is very flexible, often 323 hiding many of the details from the application. This results in 324 protocols that support multiple key management approaches. In fact, 325 the key management approach itself may be negotiable, which creates a 326 design challenge to protect the negotiation of the key management 327 approach before it is used to produce cryptographic keys. 329 Protocols can negotiate a key management approach, derive an initial 330 cryptographic key, and then authenticate the negotiation. However, 331 if the authentication fails, the only recourse is to start the 332 negotiation over from the beginning. 334 Some environments will restrict the key management approaches by 335 policy. Such policies tend to improve interoperability within a 336 particular environment, but they cause problems for individuals that 337 need to work in multiple incompatible environments. 339 2.6. Preserving Interoperability 341 Cryptographic algorithm deprecation is very hard. People do not like 342 to introduce interoperability problems, even to preserve security. 343 As a result, flawed algorithms are supported for far too long. The 345 Guidelines for Cryptographic Algorithm Agility August 2015 347 impacts of legacy software and long support tails on security can be 348 reduced by making it easy to rollover from old algorithms and suites 349 to new ones. 351 Without clear mechanisms for algorithm and suite rollover, preserving 352 interoperability becomes a difficult social problem. For example, 353 consider web browsers. Dropping support for an algorithm suite can 354 break connectivity to some web sites, and the browser vendor will 355 lose users by doing so. This situation creates incentives to support 356 algorithm suites that would otherwise be deprecated in order to 357 preserve interoperability. 359 Transition in Internet infrastructure is particularly difficult. The 360 digital signature on a trust anchor certificate [RFC5280] is often 361 expected to last decades, which hinders the transition away from a 362 weak signature algorithm or short key length. Once a long-lived 363 certificate is issued with a particular signature algorithm, that 364 algorithm will be used by many relying parties, and none of them can 365 stop supporting it without invalidating all of the subordinate 366 certificates. In a hierarchical system, many subordinate 367 certificates could be impacted by the decision to drop support for a 368 weak signature algorithm or an associated hash function. 370 Institutions, being large or dominant users within a large user base, 371 can assist by coordinating the demise of an algorithm suite, making 372 the rollover easier for their own users as well as others. 374 2.7. Balance Security Strength 376 When selecting or negotiating a suite of cryptographic algorithms, 377 the strength of each algorithm SHOULD be considered. The algorithms 378 in a suite SHOULD be roughly equal; however, the security service 379 provided by each algorithm in a particular context needs to be 380 considered in making the selection. Algorithm strength needs to be 381 considered at the time a protocol is designed. It also needs to be 382 considered at the time a protocol implementation is deployed and 383 configured. Advice from from experts is useful, but in reality, such 384 advice is often unavailable to system administrators that are 385 deploying and configuring a protocol implementation. For this 386 reason, protocol designers SHOULD provide clear guidance to 387 implementors, leading to balanced options being available at the time 388 of deployment and configuration. 390 Performance is always a factor is selecting cryptographic algorithms. 391 Performance and security need to be balanced. Some algorithms offer 392 flexibility in their strength by adjusting the key size, number of 393 rounds, authentication tag size, prime group size, and so on. For 394 example, cipher suites include Diffie-Hellman or RSA without 396 Guidelines for Cryptographic Algorithm Agility August 2015 398 specifying a particular public key length. If the algorithm 399 identifier or suite identifier named a particular public key length, 400 migration to longer ones would be more difficult. On the other hand, 401 inclusion of a public key length would make it easier to migrate away 402 from short ones when computational resources available to attacker 403 dictate the need to do so. Therefore, flexibility on asymmetric key 404 length is both desirable and undesirable at the same time. 406 In CMS [RFC5652], a previously distributed symmetric key-encryption 407 key can be used to encrypt a content-encryption key, which is in turn 408 used to encrypt the content. The key-encryption and content- 409 encryption algorithms are often different. If, for example, a 410 message content is encrypted with 128-bit AES key and the content- 411 encryption key is wrapped with a 256-bit AES key, then at most 128 412 bits of protection is provided. In this situation, the algorithm and 413 key size selections should ensure that the key encryption is at least 414 as strong as the content encryption. In general, wrapping one key 415 with another key of a different size yields the security strength of 416 the shorter key. 418 2.8. Balance Protocol Complexity 420 Protocol designers MUST be prepared for the supported cryptographic 421 algorithm set to change over time. There is a spectrum of ways to 422 enable the transition, and Section 3 discusses dome of the related 423 issues. 425 Keep implementations as simple as possible. Complex protocol 426 negotiation provides opportunities for attack, such as downgrade 427 attacks. Support for many algorithm alternatives is also harmful. 428 Both of these can lead to portions of the implementation that are 429 rarely used, increasing the opportunity for undiscovered exploitable 430 implementation bugs. 432 2.9. Opportunistic Security 434 Despite the guidance in Section 2.4, opportunistic security [RFC7435] 435 SHOULD also be considered, especially at the time a protocol 436 implementation is deployed and configured. Using algorithms that are 437 weak against advanced attackers but sufficient against others is a 438 way to make pervasive surveillance significantly more difficult. As 439 a result, algorithms that would not be acceptable in many negotiated 440 situations are acceptable for opportunistic security. Similarly, 441 weaker algorithms and shorter key sizes are also acceptable for 442 opportunistic security. That said, the use of strong algorithms is 443 always preferable. 445 Guidelines for Cryptographic Algorithm Agility August 2015 447 3. Cryptographic Algorithm Specifications 449 There are tradeoffs between the number of cryptographic algorithms 450 that are supported and the time to deploy a new algorithm. This 451 section provides some of the insights about the tradeoff faced by 452 protocol designers. 454 Ideally, two independent sets of mandatory-to-implement algorithms 455 will be specified, allowing for a primary suite and a secondary 456 suite. This approach ensures that the secondary suite is widely 457 deployed if a flaw is found in the primary one. 459 3.1. Choosing Mandatory-to-Implement Algorithms 461 It may seem as if the ability to use an algorithm of one's own 462 choosing is very desirable; however, the selection is often better 463 left to experts. Further, any and all cryptographic algorithm 464 choices ought not be available in every implementation. Mandatory- 465 to-implement algorithms ought to have a public stable specification 466 and public documentation that it has been well studied, giving rise 467 to significant confidence. The IETF has alway had a preference for 468 unencumbered algorithms. There are significant benefits in selecting 469 algorithms and suites that are widely deployed. The selected 470 algorithms need to be resistant to side-channel attacks as well as 471 meeting the performance, power, and code size requirements on a wide 472 variety of platforms. In addition, inclusion of too many 473 alternatives may add complexity to algorithm selection or 474 negotiation. 476 There is significant benefit in selecting the same algorithms and 477 suites for different protocols. Using the same algorithms can 478 simplify implementation when more than one of the protocols is used 479 in the same device or system. 481 Sometime more than one mandatory-to-implement algorithm is needed to 482 increase the likelihood of interoperability among a diverse 483 population. For example, authenticated encryption is provided by 484 AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are 485 considered to be secure. AES-CCM is available in hardware used by 486 many small devices, and AES-GCM is parallelizable and well suited 487 high-speed devices. Therefore an application needing authenticated 488 encryption might specify one of these algorithms or both of these 489 algorithms, depending of the population. 491 3.2. Too Many Choices Can Be Harmful 493 It is fairly easy to specify the use of any arbitrary cryptographic 494 algorithm, and once the specification is available, the algorithm 496 Guidelines for Cryptographic Algorithm Agility August 2015 498 gets implemented and deployed. Some people say that the freedom to 499 specify algorithms independently from the rest of the protocol has 500 lead to the specification of too many cryptographic algorithms. Once 501 deployed, even with moderate uptake, it is quite difficult to remove 502 algorithms because interoperability with some party will be impacted. 503 As a result, weaker ciphers stick around far too long. Sometimes 504 implementors are forced to maintain cryptographic algorithm 505 implementations well beyond their useful lifetime. 507 In order to manage the proliferation of algorithm choices and provide 508 an expectation of interoperability, many protocols specify mandatory- 509 to-implement algorithms or suites. All implementors are expected to 510 support the mandatory-to-implement cryptographic algorithm, and they 511 can include any others algorithms that they desire. The mandatory- 512 to-implement algorithms are chosen to be highly secure and follow the 513 guidance in RFC 1984 [RFC1984]. Of course, many other factors, 514 including intellectual property rights, have an impact on the 515 cryptographic algorithms that are selected by the community. 516 Generally, the mandatory-to-implement algorithms ought to be 517 preferred, and the other algorithms ought to be selected only in 518 special situations. However, it can be very difficult for a skilled 519 system administrator to determine the proper configuration to achieve 520 these preferences. 522 In some cases, more than one mandatory-to-implement cryptographic 523 algorithm has been specified. This is intended to ensure that at 524 least one secure cryptographic algorithm will be available, even if 525 other mandatory-to-implement algorithms are broken. To achieve this 526 goal, the selected algorithms must be diverse, so that a 527 cryptoanalytic advance against one of the algorithms does not also 528 impact the other selected algorithms. The idea is to have an 529 implemented and deployed algorithm as a fallback. However, all of 530 the selected algorithms need to be routinely exercised to ensure 531 quality implementation. This is not always easy to do, especially if 532 the various selected algorithms require different credentials. 533 Obtaining multiple credentials for the same installation is an 534 unacceptable burden on system administrators. Also, the manner by 535 which system administrators are advised to switch algorithms or 536 suites is at best ad hoc, and at worst entirely absent. 538 3.3. Picking One True Cipher Suite Can Be Harmful 540 In the past, protocol designers have chosen one cryptographic 541 algorithm or suite, and then tied many protocol details to that 542 selection. Plan for algorithm transition, either because a mistake 543 is made in the initial selection or because the protocol is 544 successfully used for a long time and the algorithm becomes weak with 545 age. Either way, the design should enable transition. 547 Guidelines for Cryptographic Algorithm Agility August 2015 549 Protocol designers are sometimes mislead by the simplicity that 550 results from selecting one true algorithm or suite. Since algorithms 551 age, the selection cannot be stable forever. Even the most simple 552 protocol needs a version number to signal which algorithm is being 553 used. This approach has at least two desirable consequences. First, 554 the protocol is simpler because there is no need for algorithm 555 negotiation. Second, system administrators do not need to make any 556 algorithm-related configuration decisions. However, the only way to 557 respond to news that the an algorithm that is part of the one true 558 cipher suite has been broken is to update the protocol specification 559 to the next version, implement the new specification, and then get it 560 deployed. 562 The first IEEE 802.11 [WiFi] specification included Wired Equivalent 563 Privacy (WEP) as the only encryption technique. Many of the protocol 564 details were driven by the selected algorithm. WEP was found to be 565 quite weak [WEP], and a very large effort was needed to specify, 566 implement, and deploy the alternative encryption techniques. This 567 effort was made even harder by the protocol design choices that were 568 tied to the initial algorithm selection and the desire for backward 569 compatibility. 571 Experience with the transition from SHA-1 to SHA-256 indicates that 572 the time from protocol specification to widespread use takes more 573 than five years. In this case, the protocol specifications and 574 implementation were straightforward and fairly prompt. In many 575 software products, the new algorithm was not considered an update to 576 existing release, so the roll out of the next release, subsequent 577 deployment, and finally adjustment of the configuration by system 578 administrators took many years. In many consumer hardware products, 579 firmware to implement the new algorithm were difficult to locate and 580 install, or the were simply not available. Further, infrastructure 581 providers were unwilling to make the transition until all of their 582 potential clients were able to use the new algorithm. 584 3.4. National Cipher Suites 586 Some nations specify cryptographic algorithms, and then require their 587 use through legislation or regulations. These algorithms may not 588 have wide public review, and they can have limited reach of 589 deployments. Yet, the legislative or regulatory mandate creates a 590 captive market. As a result, the use of such algorithms gets 591 specified, implemented, and deployed. The default server or 592 responder configuration SHOULD disable such algorithms; in this way, 593 explicit action by the system administrator is needed to enable them 594 where they are actually required. For tiny devices with no user 595 interface, an administrator action may only be possible at the time 596 the device is purchased. 598 Guidelines for Cryptographic Algorithm Agility August 2015 600 National algorithms can force an implementer to produce several 601 incompatible product releases for a different countries or regions, 602 which has significantly greater cost over development of a product 603 using a globally-acceptable algorithm. This situation could be even 604 worse if the various national algorithms impose different 605 requirements on the protocol, its key management, or its use of 606 random values. 608 4. Security Considerations 610 This document provides guidance to working groups and protocol 611 designers. The security of the Internet is improved when broken or 612 weak cryptographic algorithms can be easily replaced with strong 613 ones. 615 From a software development and maintenance perspective, 616 cryptographic algorithms can often be added and removed without 617 making changes to surrounding data structures, protocol parsing 618 routines, or state machines. This approach separates the 619 cryptographic algorithm implementation from the rest of the code, 620 which makes it easier to tackle special security concerns such as key 621 exposure and constant-time execution. 623 Sometimes application layer protocols can make use of transport layer 624 security protocols, such as TLS [RFC5246] or DTLS [RFC6347]. This 625 insulates the application layer protocol from the details of 626 cryptography, but it is likely to still be necessary to handle the 627 transition from unprotected traffic to protected traffic in the 628 application layer protocol. In addition, the application layer 629 protocol may need to handle the downgrade from encrypted 630 communication to plaintext communication. 632 Hardware offers challenges in the transition of algorithms, for both 633 tiny devices and very high-end data center equipment. Many tiny 634 devices do not include the ability to update the firmware at all. 635 Even if the firmware can be updated, tiny devices are often deployed 636 in places that make it very inconvenient to do so. High-end data 637 center equipment may use special-purpose chips to achieve very high 638 performance, which means that board-level replacement may be needed 639 to change the algorithm. Cost and down-time are both factors in such 640 an upgrade. 642 In most cases, the cryptographic algorithm remains strong, but an 643 attack is found against the way that the strong algorithm is used in 644 a particular protocol. In these cases, a protocol change will 645 probably be needed. For example, the order of cryptographic 646 operations in the TLS protocol has evolved as various attacks have 647 been discovered. Originally, TLS performed encryption after 649 Guidelines for Cryptographic Algorithm Agility August 2015 651 computation of the message authentication code (MAC). This order of 652 operations is called MAC-then-encrypt, which actually involves MAC 653 computation, padding, and then encryption. This is no longer 654 considered secure [BN][K]. As a result, a mechanism was specified to 655 use encrypt-then-MAC instead [RFC7366]. Future versions of TLS are 656 expected to use exclusively authenticated encryption algorithms 657 [RFC5166], which should resolve the ordering discussion altogether. 658 After discovery of such attacks, updating the cryptographic 659 algorithms is not likely to be sufficient to thwart the new attack. 660 It may necessary to make significant changes to the protocol. 662 Some protocols are used to protect stored data. For example, S/MIME 663 [RFC5751] can protect a message kept in a mailbox. To recover the 664 protected stored data, protocol implementations need to support older 665 algorithms, even when they no longer use the older algorithms for the 666 protection of new stored data. 668 Support for too many algorithms can lead to implementation 669 vulnerabilities. When many algorithms are supported, some of them 670 will be rarely used. Any code that is rarely used can contain 671 undetected bugs, and algorithm implementations are no different. 672 Measurements SHOULD be used to determine whether implemented 673 algorithms are actually being used, and if they are not, future 674 releases should remove them. In addition, unused algorithms or 675 suites SHOULD be marked as deprecated in the IANA registry. In 676 short, eliminate the cruft. 678 Section 2.3 talks about algorithm transition without considering any 679 other aspects of the protocol design. In practice, there are 680 dependencies between the cryptographic algorithm and other aspects of 681 the protocol. For example, the BEAST attack [BEAST] against TLS 682 [RFC5246] caused many sites to turn off modern cryptographic 683 algorithms in favor of older and clearly weaker algorithms. 685 Mechanisms for timely update of devices are needed to deploy a 686 replacement algorithm or suite. It takes a long time to specify, 687 implement, and deploy a replacement, therefore the transition process 688 needs to begin when practically exploitable flaws become known. The 689 update processes on some devices involve certification, which further 690 increases the time to deploy a replacement. For example, devices 691 that are part of health or safety systems often require certification 692 before deployment. Embedded systems and SCADA systems often have 693 upgrade cycles stretching over many years, leading to similar time to 694 deployment issues. Prompt action is needed if a replacement has any 695 hope of being deployed before exploitation techniques become widely 696 available exploits. 698 Guidelines for Cryptographic Algorithm Agility August 2015 700 5. IANA Considerations 702 This document does not establish any new IANA registries, nor does it 703 add any entries to existing registries. 705 This document does RECOMMEND a convention for new registries for 706 cryptographic algorithm or suite identifiers. Once an algorithm or 707 suite identifier is added to the registry, it SHOULD NOT be changed 708 or removed. However, it is desirable to include a means of marking a 709 registry entry as deprecated when implementation is no longer 710 advisable. 712 6. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 718 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 719 April 2004. 721 7. Informative References 723 [BEAST] http://en.wikipedia.org/wiki/ 724 Transport_Layer_Security#BEAST_attack. 726 [BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: 727 Relations among notions and analysis of the generic 728 composition paradigm", Proceedings of AsiaCrypt '00, 729 Springer-Verlag LNCS No. 1976, p. 531, December 2000. 731 [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of 732 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 733 Special Publication 800-30D, November 2007. 735 [K] Krawczyk, H., "The Order of Encryption and Authentication 736 for Protecting Communications (or: How Secure Is SSL?)", 737 Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, 738 p. 310, August 2001. 740 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 741 Technology and the Internet", RFC 1984, August 1996. 743 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 744 Engineering Task Force Standard Protocols", BCP 61, RFC 745 3365, August 2002. 747 Guidelines for Cryptographic Algorithm Agility August 2015 749 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 750 CBC-MAC (CCM)", RFC 3610, September 2003. 752 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 753 2005. 755 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 756 RFC 4303, December 2005. 758 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 759 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 760 December 2005. 762 [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion 763 Control Mechanisms", RFC 5166, March 2008. 765 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 766 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 768 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 769 Housley, R., and W. Polk, "Internet X.509 Public Key 770 Infrastructure Certificate and Certificate Revocation List 771 (CRL) Profile", RFC 5280, May 2008. 773 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 774 RFC 5652, September 2009. 776 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 777 Mail Extensions (S/MIME) Version 3.2 Message 778 Specification", RFC 5751, January 2010. 780 [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 781 Security Version 1.2", RFC 6347, January 2012. 783 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 784 Procedure for the Resource Public Key Infrastructure 785 (RPKI)", BCP 182, RFC 6916, April 2013. 787 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm 788 Understanding in DNS Security Extensions (DNSSEC)", 789 RFC 6975, July 2013. 791 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 792 Kivinen, "Internet Key Exchange Protocol Version 2 793 (IKEv2)", STD 79, RFC 7296, October 2014. 795 Guidelines for Cryptographic Algorithm Agility August 2015 797 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security 798 (TLS) and Datagram Transport Layer Security (DTLS)", 799 RFC 7366, September 2014. 801 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most 802 of the Time", RFC 7435, December 2014. 804 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations 805 for Secure Use of Transport Layer Security (TLS) and 806 Datagram Transport Layer Security (DTLS)", RFC 7525, 807 BCP 195, May 2015. 809 [WEP] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy 811 [WiFi] IEEE , "Wireless LAN Medium Access Control (MAC) And 812 Physical Layer (PHY) Specifications, IEEE Std 802.11-1997, 813 1997. 815 Acknowledgements 817 Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon 818 Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, 819 Tony Finch, Ian Grigg, Peter Gutmann, Wes Hardaker, Joe Hildebrand, 820 Paul Hoffman, Phillip Hallam-Baker, Christian Huitema, Watson Ladd, 821 Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Yoav 822 Nir, Wendy Seltzer, Rich Salz, Rene Struik, Kristof Teichel, Martin 823 Thompson, Jeffrey Walton, Nico Williams, and Peter Yee for their 824 review and insightful comments. While some of these people do not 825 agree with some aspects of this document, the discussion that 826 resulted for their comments has certainly resulted in a better 827 document. 829 Author's Address 831 Russ Housley 832 Vigil Security, LLC 833 918 Spring Knoll Drive 834 Herndon, VA 20170 835 USA 836 EMail: housley@vigilsec.com