idnits 2.17.00 (12 Aug 2021) /tmp/idnits46083/draft-iab-crypto-alg-agility-04.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 -- The document date (22 May 2015) is 2556 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 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: 23 November 2015 22 May 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 or become more feasible for more attackers. 73 Algorithm agility is achieved when a protocol can easily migrate from 74 one algorithm suite to another, more desirable one, over time. For 75 the protocol implementer, this means that implementations should be 76 modular to easily accommodate the insertion of new algorithms or 77 suites of algorithms. Ideally, implementations will also provide a 78 way to measure when deployed implementations have shifted away from 79 the old algorithms and to the better ones. For the protocol 80 designer, algorithm agility means that one or more algorithm 81 identifier must be supported, the set of mandatory-to-implement 82 algorithms will change over time, and an IANA registry of algorithm 83 identifiers will be needed. 85 Algorithm identifiers by themselves are not sufficient to ensure easy 86 migration. Action by people that maintain implementations and 87 operate services is needed to develop, deploy, and adjust 88 configuration settings to enable the new more desirable algorithms 89 and to deprecate or disable older, less desirable ones. In a perfect 90 world, this takes place before the older algorithm or suite of 91 algorithms is catastrophically weakened. However, experience has 92 shown that many people are unwilling to disable older weaker 93 algorithms; it seems that these people prefer to live with weaker 94 algorithms, sometimes seriously flawed ones, to maintain 95 interoperability with older software well after experts recommend 96 migration. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Algorithm Agility Guidelines 106 These guidelines are for use by IETF working groups and protocol 107 authors for IETF protocols that make use of cryptographic algorithms. 109 2.1. Algorithm Identifiers 111 IETF protocols that make use of cryptographic algorithms MUST support 112 one or more algorithm or suite identifier. The identifier might be 113 explicitly carried in the protocol. Alternatively, it can configured 114 by a management mechanism. For example, an entry in a key table that 115 includes a key value and an algorithm identifier might be sufficient. 117 Some approaches carry one identifier for each algorithm that is used. 118 Other approaches carry one identifier for a full suite of algorithms. 119 Both approaches are used in IETF protocols. Designers are encouraged 120 to pick one of these approaches and use it consistently throughout 121 the protocol or family of protocols. Suite identifiers make it 122 easier for the protocol designer to ensure that the algorithm 123 selections are complete and compatible for future assignments. 124 However, suite identifiers inherently face a combinatoric explosion 125 as new algorithms are defined. Algorithm identifiers, on the other 126 hand, impose a burden on implementations by forcing a determination 127 at run-time regarding which algorithm combinations are acceptable. 129 Regardless of the approach used, protocols historically negotiate the 130 symmetric cipher and cipher mode together to ensure that they are 131 completely compatible. 133 In the IPsec protocol suite, IKEv2 [RFC7296] carries the algorithm 134 identifiers for AH [RFC4302] and ESP [RFC4303]. Such separation is a 135 completely fine design choice. In contrast, TLS [RFC5246] carries 136 cipher suite identifiers, which is also a completely fine design 137 choice. 139 An IANA registry SHOULD be used for these algorithm or suite 140 identifiers. Once an algorithm identifier is added to the registry, 141 it should not be changed or removed. However, it is desirable to 142 mark a registry entry as deprecated when implementation is no longer 143 advisable. 145 2.2. Mandatory-to-Implement Algorithms 147 For secure interoperability, BCP 61 [RFC3365] recognizes that 148 communicating peers that use cryptographic mechanisms must support a 149 common set of strong cryptographic algorithms. For this reason, the 150 protocol MUST specify one or more mandatory-to-implement algorithm or 151 suite. Note that this is not done for protocols that are embedded in 152 other protocols, where the system-level protocol specification 153 identifies the mandatory-to-implement algorithm or suite. For 154 example, S/MIME [RFC5751] makes use of the cryptographic message 155 Syntax (CMS) [RFC5652], and S/MIME specifies the mandatory-to- 156 implement algorithms, not CMS. This approach allows other protocols 157 can make use of CMS and make different mandatory-to-implement 158 algorithm choices. 160 The IETF needs to be able to change the mandatory-to-implement 161 algorithms over time. It is highly desirable to make this change 162 without updating the base protocol specification. To achieve this 163 goal, the base protocol specification includes a reference to a 164 companion algorithms document, allowing the update of one document 165 without necessarily requiring an update to the other. This division 166 also facilitates the advancement of the base protocol specification 167 on the standards maturity ladder even if the algorithm document 168 changes frequently. 170 The IETF SHOULD keep the set of mandatory-to-implement algorithms 171 small. To do so, the set of algorithms will necessarily change over 172 time, and the transition SHOULD happen before the algorithms in the 173 current set have weakened to the breaking point. 175 Some cryptographic algorithms are inherently tied to a specific key 176 size, but others allow many different key sizes. Likewise, some 177 algorithms support parameters of different sizes, such as integrity 178 check values or nonces. The algorithm specification MUST identify 179 the specific key sizes and parameter sizes that are to be supported. 180 When more than one key size is available, expect the mandatory-to- 181 implement key size to increase over time. 183 Guidance on cryptographic key size for asymmetric keys can be found 184 in BCP 86 [RFC3766]. 186 Guidance on cryptographic key size for symmetric keys can be found in 187 BCP 195 [RFC7525]. 189 2.3. Transition from Weak Algorithms 191 Transition from an old algorithm that is found to be weak can be 192 tricky. It is of course straightforward to specify the use of a new, 193 better algorithm. And then, when the new algorithm is widely 194 deployed, the old algorithm ought no longer be used. However, 195 knowledge about the implementation and deployment of the new 196 algorithm will always be imperfect, so one cannot be completely 197 assured of interoperability with the new algorithm. 199 Algorithm transition is naturally facilitated as part of an algorithm 200 selection or negotiation mechanism. Protocols MUST facilitate the 201 selection to the best algorithm or suite that is supported by all 202 communicating peers. In addition, a mechanism is needed to determine 203 whether the new algorithm has been deployed. For example, the DNSSEC 204 EDNS0 option [RFC6975] measures the acceptance and use of new digital 205 signing algorithms. 207 In the worst case, the old algorithm may be found to be tragically 208 flawed, permitting a casual attacker to download a simple script to 209 break it. Sadly, this has happened when a secure algorithm is used 210 incorrectly or used with poor key management, resulting in a weak 211 cryptographic algorithm suite. In such situations, the protection 212 offered by the algorithm is severely compromised, perhaps to the 213 point that one wants to stop using the weak suite altogether, 214 rejecting offers to use the weak suite well before the new suite is 215 widely deployed. 217 In any case, there comes a point in time where one refuses to use the 218 old, weak algorithm or suite. This can happen on a flag day, or each 219 installation can select a date on their own. 221 2.4. Balance Security Strength 223 When selecting a suite of cryptographic algorithms, the strength of 224 each algorithm SHOULD be considered. It needs to be considered at 225 the time a protocol is designed. It also needs to be considered at 226 the time a protocol implementation is deployed and configured. 227 Advice from from experts is useful, but in reality, it is not often 228 available to system administrators that are deploying and configuring 229 a protocol implementation. For this reason, protocol designers 230 SHOULD provide clear guidance to implementors, leading to balanced 231 options being available at the time of deployment and configuration. 233 Cipher suites include Diffie-Hellman or RSA without specifying a 234 particular public key length. If the algorithm identifier or suite 235 identifier named a particular public key length, migration to longer 236 ones would be more difficult. On the other hand, inclusion of a 237 public key length would make it easier to migrate away from short 238 ones when computational resources available to attacker dictate the 239 need to do so. Therefore, flexibility on asymmetric key length is 240 both desirable and undesirable at the same time. 242 In CMS [RFC5652], a previously distributed symmetric key-encryption 243 key can be used to encrypt a content-encryption key, which is in turn 244 used to encrypt the content. The key-encryption and content- 245 encryption algorithms are often different. If, for example, a 246 message content is encrypted with 128-bit AES key and the content- 247 encryption key is wrapped with a 256-bit AES key, then at most 128 248 bits of protection is provided. In this situation, the algorithm and 249 key size selections should ensure that the key encryption is at least 250 as strong as the content encryption. In general, wrapping one key 251 with another key of a different size yields the security strength of 252 the shorter key. 254 2.5. Opportunistic Security 256 Despite the guidance in Section 2.4, opportunistic security [RFC7435] 257 SHOULD also be considered, especially at the time a protocol 258 implementation is deployed and configured. While RSA with a 2048-bit 259 public key is quite a bit stronger than SHA-1, it is quite reasonable 260 to use them together if the alternative is no authentication 261 whatsoever. That said, the use of strong algorithms is always 262 preferable. 264 3. Algorithm Agility in Protocol Design 266 Some attempts at algorithm agility have not been completely 267 successful. This section provides some of the insights based on 268 protocol designs and deployments. 270 3.1. Algorithm Identifiers 272 If a protocol does not carry an algorithm identifier, then the 273 protocol version number or some other major change is needed to 274 transition from one algorithm to another. The inclusion of an 275 algorithm identifier is a minimal step toward cryptographic algorithm 276 agility. In addition, an IANA registry is needed to pair the 277 identifier with an algorithm specification. 279 Sometimes a combination of protocol version number and explicit 280 algorithm or suite identifiers is appropriate. For example, the TLS 281 version number names the default key derivation function and the 282 cipher suite identifier names the rest of the needed algorithms. 284 Sometimes application layer protocols can make use of transport layer 285 security protocols, such as TLS or DTLS. This insulates the 286 application layer protocol from the details of cryptography, but it 287 is likely to still be necessary to handle the transition from 288 unprotected traffic to protected traffic in the application layer 289 protocol. In addition, the application layer protocol may need to 290 handle the downgrade from encrypted communication to plaintext 291 communication. 293 3.2. Migration Mechanisms 295 Cryptographic algorithm selection or negotiation SHOULD be integrity 296 protected. If selection is not integrity protected, then the 297 protocol will be subject to a downgrade attack. Without integrity 298 protection of algorithm or suite selection, the attempt to transition 299 to a new algorithm or suite may introduce new opportunities for 300 downgrade attack. 302 If a protocol specifies a single mandatory-to-implement integrity 303 algorithm, eventually that algorithm will be found to be weak. 305 Extra care is needed when a mandatory-to-implement algorithm is used 306 to provide integrity protection for the negotiation of other 307 cryptographic algorithms. In this situation, a flaw in the 308 mandatory-to-implement algorithm may allow an attacker to influence 309 the choices of the other algorithms. 311 Performance is always a factor is selecting cryptographic algorithms. 312 In many algorithms, shorter keys offer higher performance, but less 313 security. Performance and security need to be balanced. Yet, all 314 algorithms age, and the advances in computing power available to the 315 attacker will eventually make any algorithm obsolete. For this 316 reason, protocols need mechanisms to migrate from one algorithm suite 317 to another over time, including the algorithm used to provide 318 integrity protection for algorithm negotiation. 320 3.3. Preserving Interoperability 322 Cryptographic algorithm deprecation is very hard. People do not like 323 to introduce interoperability problems, even to preserve security. 324 As a result, flawed algorithms are supported for far too long. The 325 impacts of legacy software an long support tails on security can be 326 reduced by making it easy to develop, deploy, and configure new 327 algorithms. 329 3.4. Cryptographic Key Management 331 Traditionally, protocol designers have avoided more than one approach 332 to key management because it makes the security analysis of the 333 overall protocol more difficult. When frameworks such as EAP and 334 GSSAPI are employed, the key management is very flexible, often 335 hiding many of the details from the application. This results in 336 protocols that support multiple key management approaches. In fact, 337 the key management approach itself may be negotiable, which creates a 338 design challenge to protect the negotiation of the key management 339 approach before it is used to produce cryptographic keys. 341 Protocols can negotiate a key management approach, derive an initial 342 cryptographic key, and then authenticate the negotiation. However, 343 if the authentication fails, the only recourse is to start the 344 negotiation over from the beginning. 346 Some environments will restrict the key management approaches by 347 policy. Such policies tend to improve interoperability within a 348 particular environment, but they cause problems for individuals that 349 need to work in multiple incompatible environments. 351 4. Cryptographic Algorithm Specifications 353 There are tradeoffs between the number of cryptographic algorithms 354 that are supported, time to deploy a new algorithm, and protocol 355 complexity. This section provides some of the insights about the 356 tradeoff faced by protocol designers. 358 Ideally, two independent sets of mandatory-to-implement algorithms 359 will be specified, allowing for a primary suite and a secondary 360 suite. This approach ensures that the secondary suite is widely 361 deployed if a flaw is found in the primary one. 363 4.1. Choosing Mandatory-to-Implement Algorithms 365 It seems like the ability to use an algorithm of one's own choosing 366 is very desirable; however, the selection is often better left to 367 experts. Further, any and all cryptographic algorithm choices ought 368 not be available in every implementation. Mandatory-to-implement 369 algorithms ought to have a public stable specification and public 370 documentation that it has been well studied, giving rise to 371 significant confidence. The IETF has alway had a preference for 372 unencumbered algorithms. The selected algorithms need to be 373 resistant to side-channel attacks as well as meeting the performance, 374 power, and code size requirements on a wide variety of platforms. In 375 addition, inclusion of too many alternatives may add complexity to 376 algorithm selection or negotiation. 378 Sometime more than one mandatory-to-implement algorithm is needed to 379 increase the likelihood of interoperability among a diverse 380 population. For example, authenticated encryption is provided by 381 AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are 382 considered to be secure. AES-CCM is available in hardware used by 383 many small devices, and AES-GCM is parallelizable and well suited 384 high-speed devices. Therefore an application needing authenticated 385 encryption might specify one of these algorithms or both of these 386 algorithms, depending of the population. 388 4.2. Too Many Choices Can Be Harmful 390 It is fairly easy to specify the use of any arbitrary cryptographic 391 algorithm, and once the specification is available, the algorithm 392 gets implemented and deployed. Some people say that the freedom to 393 specify algorithms independently from the rest of the protocol has 394 lead to the specification of too many cryptographic algorithms. Once 395 deployed, even with moderate uptake, it is quite difficult to remove 396 algorithms because interoperability with some party will be impacted. 397 As a result, weaker ciphers stick around far too long. Sometimes 398 implementors are forced to maintain cryptographic algorithm 399 implementations well beyond their useful lifetime. 401 In order to manage the proliferation of algorithm choices and provide 402 an expectation of interoperability, many protocols specify mandatory- 403 to-implement algorithms or suites. All implementors are expected to 404 support the mandatory-to-implement cryptographic algorithm, and they 405 can include any others algorithms that they desire. The mandatory- 406 to-implement algorithms are chosen to be highly secure and follow the 407 guidance in RFC 1984 [RFC1984]. Of course, many other factors, 408 including intellectual property rights, have an impact on the 409 cryptographic algorithms that are selected by the community. 410 Generally, the mandatory-to-implement algorithms ought to be 411 preferred, and the other algorithms ought to be selected only in 412 special situations. However, it can be very difficult for a skilled 413 system administrator to determine the proper configuration to achieve 414 these preferences. 416 In some cases, more than one mandatory-to-implement cryptographic 417 algorithm has been specified. This is intended to ensure that at 418 least one secure cryptographic algorithm will be available, even if 419 other mandatory-to-implement algorithms are broken. To achieve this 420 goal, the selected algorithms must be diverse, so that a 421 cryptoanalytic advance against one of the algorithms does not also 422 impact the other selected algorithms. The idea is to have an 423 implemented and deployed algorithm as a fallback. However, all of 424 the selected algorithms need to be routinely exercised to ensure 425 quality implementation. This is not always easy to do, especially if 426 the various selected algorithms require different credentials. 427 Obtaining multiple credentials for the same installation is an 428 unacceptable burden on system administrators. Also, the manner by 429 which system administrators are advised to switch algorithms or 430 suites is at best ad hoc, and at worst entirely absent. 432 4.3. Picking One True Cipher Suite Can Be Harmful 434 In the past, protocol designers have chosen one cryptographic 435 algorithm or suite, and then tied many protocol details to that 436 selection. It is much better to plan for algorithm transition, 437 either because a mistake is made in the initial selection or because 438 the protocol is successfully used for a long time and the algorithm 439 becomes week with age. Either way, the design should enable 440 transition. 442 Protocol designers are sometimes mislead by the simplicity that 443 results from selecting one true algorithm or suite. Since algorithms 444 age, the selection cannot be stable forever. Even the most simple 445 protocol needs a version number to signal which algorithm that is 446 being used. This approach has at least two desirable consequences. 447 First, the protocol is simpler because there is no need for algorithm 448 negotiation. Second, system administrators do not need to make any 449 algorithm-related configuration decisions. However, the only way to 450 respond to news that the an algorithm that is part of the one true 451 cipher suite has been broken is to update the protocol specification 452 to the next version, implement the new specification, and then get it 453 deployed. 455 The first IEEE 802.11 [WiFi] specification included the Wired 456 Equivalent Privacy (WEP) as the only encryption technique. WEP was 457 found to be quite weak [WEP], and a very large effort was needed to 458 specify, implement, and deploy the alternative encryption techniques. 460 Experience with the transition from SHA-1 to SHA-256 indicates that 461 the time from protocol specificate to widespread use takes more than 462 five years. In this case, the protocol specifications and 463 implementation were straightforward and fairly prompt. In many 464 software products, the new algorithm was not considered an update to 465 existing release, so the roll out of the next release, subsequent 466 deployment, and finally adjustment of the configuration by system 467 administrators took many years. In many consumer hardware products, 468 firmware to implement the new algorithm were difficult to locate and 469 install, or the were simply not available. Further, infrastructure 470 providers were unwilling to make the transition until all of their 471 potential clients were able to use the new algorithm. 473 4.4. National Cipher Suites 475 Some nations specify cryptographic algorithms, and then require their 476 use through legislation or regulations. These algorithms may not 477 have wide public review, and they can have limited reach of 478 deployments. Yet, the legislative or regulatory mandate creates a 479 captive market. As a result, the use of such algorithms get 480 specified, implemented, and deployed. The default server-side 481 configuration SHOULD disable such algorithms; in this way, explicit 482 action by the system administrator is needed to enable them where 483 they are actually required. 485 4.5. Balance Protocol Complexity 487 Protocol designers MUST be prepared for the supported cryptographic 488 algorithm set to change over time. As shown by the discussion in the 489 previous two sections, there is a spectrum of ways to enable the 490 transition. 492 Keep implementations as simple as possible. Complex protocol 493 negotiation provides opportunities for attack, such as downgrade 494 attacks. Support for many algorithm alternatives is also harmful, as 495 discussed in Section 4.1. Both of these can lead to portions of the 496 implementation that are rarely used, increasing the opportunity for 497 undiscovered exploitable implementation bugs. 499 4.6. Providing Notice 501 Fortunately, catastrophic algorithm failures without warning are 502 rare. More often, algorithm transition is the result of age. For 503 example, the transition from DES to Triple-DES to AES took place over 504 decades, causing a shift in symmetric block cipher strength from 56 505 bits to 112 bits to 128 bits. Where possible, authors SHOULD provide 506 notice to implementers about expected algorithm transitions. One 507 approach is to use SHOULD+, SHOULD-, and MUST- in the specification 508 of algorithms. 510 SHOULD+ This term means the same as SHOULD. However, it is 511 likely that an algorithm marked as SHOULD+ will be 512 promoted to a MUST in the future. 514 SHOULD- This term means the same as SHOULD. However, it is 515 likely that an algorithm marked as SHOULD- will be 516 deprecated to a MAY or worse in the future. 518 MUST- This term means the same as MUST. However, it is 519 expected that an algorithm marked as MUST- will be 520 downgraded in the future. Although the status of the 521 algorithm will be determined at a later time, it is 522 reasonable to expect that a the status of a MUST- 523 algorithm will remain at least a SHOULD or a SHOULD-. 525 5. Security Considerations 527 This document provides guidance to working groups and protocol 528 designers. The security of the Internet is improved when broken or 529 weak cryptographic algorithms can be easily replaced with strong 530 ones. 532 From a software development and maintenance perspective, 533 cryptographic algorithms can often be added and removed without 534 making changes to surrounding data structures, protocol parsing 535 routines, or state machines. This approach separates the 536 cryptographic algorithm implementation from the rest of the code, 537 which makes it easier to tackle special security concerns such as key 538 exposure and constant-time execution. 540 The situation is different for hardware, for both tiny devices and 541 very high-end data center equipment. Many tiny devices do not 542 include the ability to update the firmware at all. Even if the 543 firmware can be updated, tiny devices are often deployed in places 544 that make it very inconvenient to do so. High-end data center 545 equipment may use special-purpose chips to achieve very high 546 performance, which means that board-level replacement may be needed 547 to change the algorithm. Cost and down-time are both factors in such 548 an upgrade. 550 In most cases, the cryptographic algorithm remains strong, but an 551 attack is found against the way that the strong algorithm is used in 552 a particular protocol. In these cases, a protocol change will 553 probably be needed. For example, the order of cryptographic 554 operations in the TLS protocol has evolved as various attacks have 555 been discovered. Originally, TLS performed encryption after 556 computation of the message authentication code (MAC). This order of 557 operations is called MAC-then-encrypt, which actually involves MAC 558 computation, padding, and then encryption. This is no longer 559 considered secure [BN][K]. As a result, a mechanism was specified to 560 use encrypt-then-MAC instead [RFC7366]. Future versions of TLS are 561 expected to use exclusively authenticated encryption algorithms 562 [RFC5166], which should resolve the ordering discussion altogether. 563 After discovery of such attacks, updating the cryptographic 564 algorithms is not likely to be sufficient to thwart the new attack. 565 It may necessary to make significant changes to the protocol. 567 Some protocols are used to protected stored data. For example, 568 S/MIME [RFC5751] can protect a message kept in a mailbox. To recover 569 the protected stored data, protocol implementations need to support 570 older algorithms, even when they no longer use the older algorithms 571 for the protection of new stored data. 573 Support for too many algorithms can lead to implementation 574 vulnerabilities. When many algorithms are supported, some of them 575 will be rarely used. Any code that is rarely used can contain 576 undetected bugs, and algorithm implementations are no different. 577 Measurements SHOULD be used to determine whether implemented 578 algorithms are actually being used, and if they are not, future 579 releases should remove them. In addition, unused algorithms or 580 suites SHOULD be marked as deprecated in the IANA registry. In 581 short, eliminate the cruft. 583 Section 2.3 talks about algorithm transition without considering any 584 other aspects of the protocol design. In practice, there are 585 dependencies between the cryptographic algorithm and other aspects of 586 the protocol. For example, the BEAST attack [BEAST] against TLS 587 [RFC5246] caused many sites to turn off modern cryptographic 588 algorithms in favor of older and clearly weaker algorithms. 590 6. IANA Considerations 592 This document does not establish any new IANA registries, nor does it 593 add any entries to existing registries. 595 This document does RECOMMEND a convention for new registries for 596 cryptographic algorithm or suite identifiers. Once an algorithm or 597 suite identifier is added to the registry, it SHOULD NOT be changed 598 or removed. However, it is desirable to include a means of marking a 599 registry entry as deprecated when implementation is no longer 600 advisable. 602 7. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 608 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 609 April 2004. 611 8. Informative References 613 [BEAST] http://en.wikipedia.org/wiki/ 614 Transport_Layer_Security#BEAST_attack. 616 [BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: 617 Relations among notions and analysis of the generic 618 composition paradigm", Proceedings of AsiaCrypt '00, 619 Springer-Verlag LNCS No. 1976, p. 531, December 2000. 621 [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of 622 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 623 Special Publication 800-30D, November 2007. 625 [K] Krawczyk, H., "The Order of Encryption and Authentication 626 for Protecting Communications (or: How Secure Is SSL?)", 627 Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, 628 p. 310, August 2001. 630 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 631 Technology and the Internet", RFC 1984, August 1996. 633 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 634 Engineering Task Force Standard Protocols", BCP 61, RFC 635 3365, August 2002. 637 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 638 CBC-MAC (CCM)", RFC 3610, September 2003. 640 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 641 2005. 643 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 644 RFC 4303, December 2005. 646 [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion 647 Control Mechanisms", RFC 5166, March 2008. 649 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 650 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 652 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 653 RFC 5652, September 2009. 655 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 656 Mail Extensions (S/MIME) Version 3.2 Message 657 Specification", RFC 5751, January 2010. 659 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm 660 Understanding in DNS Security Extensions (DNSSEC)", 661 RFC 6975, July 2013. 663 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 664 Kivinen, "Internet Key Exchange Protocol Version 2 665 (IKEv2)", STD 79, RFC 7296, October 2014. 667 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security 668 (TLS) and Datagram Transport Layer Security (DTLS)", 669 RFC 7366, September 2014. 671 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most 672 of the Time", RFC 7435, December 2014. 674 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations 675 for Secure Use of Transport Layer Security (TLS) and 676 Datagram Transport Layer Security (DTLS)", RFC 7525, 677 BCP 195, May 2015. 679 [WEP] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy 681 [WiFi] IEEE , "Wireless LAN Medium Access Control (MAC) And 682 Physical Layer (PHY) Specifications, IEEE Std 802.11-1997, 683 1997. 685 Acknowledgements 687 Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon 688 Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, 689 Tony Finch, Ian Grigg, Peter Gutmann, Wes Hardaker, Joe Hildebrand, 690 Christian Huitema, Watson Ladd, Paul Lambert, Ben Laurie, Eliot Lear, 691 Nikos Mavrogiannopoulos, Yoav Nir, Rich Salz, Kristof Teichel, 692 Jeffrey Walton, Nico Williams, and Peter Yee for their review and 693 insightful comments. While some of these people do not agree with 694 some aspects of this document, the discussion that resulted for their 695 comments has certainly resulted in a better document. 697 Author's Address 699 Russ Housley 700 Vigil Security, LLC 701 918 Spring Knoll Drive 702 Herndon, VA 20170 703 USA 704 EMail: housley@vigilsec.com