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