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