idnits 2.17.00 (12 Aug 2021) /tmp/idnits47011/draft-iab-crypto-alg-agility-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 212 has weird spacing: '...ding to balan...' == Line 299 has weird spacing: '...ing the algor...' == Line 474 has weird spacing: '...rotocol parsi...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (1 May 2015) is 2577 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 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 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: 2 November 2015 1 May 2015 6 Guidelines for Cryptographic Algorithm Agility 7 9 Abstract 11 Many IETF protocols use cryptographic algorithms to provide 12 confidentiality, integrity, authentication or digital signature. 13 Communicating peers must support a common set of cryptographic 14 algorithms for these mechanisms to work properly. This memo provides 15 guidelines to ensure that protocols have the ability to migrate from 16 one algorithm suite to another over time. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 Many IETF protocols use cryptographic algorithms to provide 57 confidentiality, integrity, authentication, or digital signature. 58 For interoperability, communicating peers must support a common set 59 of cryptographic algorithms. In most cases, a combination of 60 compatible cryptographic algorithms will be used to provide the 61 desired security services. The set of cryptographic algorithms being 62 used at a particular time is often referred to as a cryptographic 63 algorithm suite or cipher suite. 65 Cryptographic algorithms age; they become weaker with time. As new 66 cryptanalysis techniques are developed and computing capabilities 67 improve, the work factor to break a particular cryptographic 68 algorithm will reduce or become more feasible for more attackers. 70 Algorithm agility is achieved when a protocol can easily migrate from 71 one algorithm suite to another, more desirable one, over time. For 72 the protocol implementer, this means that implementations should be 73 modular to easily accommodate the insertion of new algorithms or 74 suites of algorithms. For the protocol designer, this means that one 75 or more algorithm identifier must be carried, the set of mandatory- 76 to-implement algorithms will change over time, and an IANA registry 77 of algorithm identifiers will be needed. These algorithm identifiers 78 might name a single cryptographic algorithm or a suite of algorithms. 80 Algorithm identifiers by themselves are not sufficient to ensure easy 81 migration. Action by people that maintain implementations and 82 operate services is needed to develop, deploy, and adjust 83 configuration settings to enable the new more desirable algorithms 84 and to deprecate or disable older, less desirable ones. Ideally, 85 this takes place before the older algorithm or suite of algorithms is 86 catastrophically weakened. Experience shows that many people are 87 unwilling to disable older weaker algorithms; it seems that these 88 people prefer to live with weaker algorithms, sometimes seriously 89 flawed ones, to maintain interoperability with older software well 90 after experts recommend migration. 92 1.1. Terminology 94 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 95 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 96 document, are to be interpreted as described in [RFC2119]. 98 2. Algorithm Agility Guidelines 100 These guidelines are for use by IETF working groups and protocol 101 authors for IETF protocols that make use of cryptographic algorithms. 103 2.1. Algorithm Identifiers 105 IETF protocols that make use of cryptographic algorithms MUST carry 106 one or more algorithm or suite identifier. 108 Some approaches carry one identifier for each algorithm that is used. 109 Other approaches carry one identifier for a suite of algorithms. 110 Both approaches are used in IETF protocols. Designers are encouraged 111 to pick one of these approaches and use it consistently throughout 112 the protocol or family of protocols. Suite identifiers make it 113 easier for the protocol designer to ensure that the algorithm 114 selections are complete and compatible for future assignments. 115 However, suite identifiers inherently face a combinatoric explosion 116 as new algorithms are defined. Algorithm identifiers, on the other 117 hand, impose a burden on implementations by forcing a determination 118 at run-time regarding which algorithm combinations are acceptable. 120 Regardless of the approach used, protocols historically negotiate the 121 symmetric cipher and cipher mode together to ensure that they are 122 completely compatible. 124 In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the 125 algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such 126 separation is a completely fine design choice. In contrast, TLS 127 [RFC5246] carries cipher suite identifiers, which is also a 128 completely fine design choice. 130 An IANA registry SHOULD be used for these algorithm or suite 131 identifiers. 133 2.2. Mandatory-to-Implement Algorithms 135 For secure interoperability, BCP 61 [RFC3365] recognizes that 136 communicating peers that use cryptographic mechanisms must support a 137 common set of strong cryptographic algorithms. For this reason, the 138 protocol MUST specify one or more mandatory-to-implement algorithm or 139 suite. Note that this is not done for protocols that are embedded in 140 other protocols, where the system-level protocol specification 141 identifies the mandatory-to-implement algorithm or suite. For 142 example, S/MIME [RFC5751] makes use of the cryptographic message 143 Syntax (CMS) [RFC5652], and S/MIME specifies the mandatory-to- 144 implement algorithms, not CMS. This approach allows other protocols 145 can make use of CMS and make different mandatory-to-implement 146 algorithm choices. 148 The IETF needs to be able to change the mandatory-to-implement 149 algorithms over time. It is highly desirable to make this change 150 without updating the base protocol specification. To achieve this 151 goal, the base protocol specification includes a reference to a 152 companion algorithms document, allowing the update of one document 153 without necessarily requiring an update to the other. This division 154 also facilitates the advancement of the base protocol specification 155 on the standards maturity ladder even if the algorithm document 156 changes frequently. 158 Some cryptographic algorithms are inherently tied to a specific key 159 size, but others allow many different key sizes. Likewise, some 160 algorithms support parameters of different sizes, such as integrity 161 check values or nonces. The algorithm specification MUST identify 162 the specific key sizes and parameter sizes that are to be supported. 163 When more than one key size is available, expect the mandatory-to- 164 implement key size to increase over time. 166 Guidance on cryptographic key size for asymmetric keys can be found 167 in BCP 86 [RFC3766]. 169 Symmetric keys used for protection of long-term values SHOULD be at 170 least 128 bits. 172 2.3. Transition from Weak Algorithms 174 Transition from an old algorithm that is found to be weak can be 175 tricky. It is of course straightforward to specify the use of a new, 176 better algorithm. And then, when the new algorithm is widely 177 deployed, the old algorithm ought no longer be used. However, 178 knowledge about the implementation and deployment of the new 179 algorithm will always be imperfect, so one cannot be completely 180 assured of interoperability with the new algorithm. 182 To facilitate transition, protocols MUST be able to advertise which 183 algorithms are supported. This may naturally occur as part of an 184 algorithm selection or negotiation mechanism, and other times a 185 mechanism is needed to determine whether the new algorithm has been 186 deployed. For example, the DNSSEC EDNS0 option [RFC6975] measures 187 the acceptance and use of new digital signing algorithms. 189 In the worst case, the old algorithm may be found to be tragically 190 flawed, permitting a casual attacker to download a simple script to 191 break it. Sadly, this has happened when a secure algorithm is used 192 incorrectly or used with poor key management, resulting in a weak 193 cryptographic algorithm suite. In such situations, the protection 194 offered by the algorithm is severely compromised, perhaps to the 195 point that one wants to stop using the weak suite altogether, 196 rejecting offers to use the weak suite well before the new suite is 197 widely deployed. 199 In any case, there comes a point in time where one refuses to use the 200 old, weak algorithm or suite. This can happen on a flag day, or each 201 installation can select a date on their own. 203 2.4. Balance Security Strength 205 When selecting a suite of cryptographic algorithms, the strength of 206 each algorithm SHOULD be considered. It needs to be considered at 207 the time a protocol is designed. It also needs to be considered at 208 the time a protocol implementation is deployed and configured. 209 Advice from from experts is useful, but in reality, it is not often 210 available to system administrators that are deploying and configuring 211 a protocol implementation. For this reason, protocol designers 212 SHOULD provide clear guidance to implementors, leading to balanced 213 options being available at the time of deployment and configuration. 215 Cipher suites include Diffie-Hellman or RSA without specifying a 216 particular public key length. If the algorithm identifier or suite 217 identifier named a particular public key length, migration to longer 218 ones would be more difficult. On the other hand, inclusion of a 219 public key length would make it easier to migrate away from short 220 ones when computational resources available to attacker dictate the 221 need to do so. Therefore, flexibility on asymmetric key length is 222 both desirable and undesirable at the same time. 224 In CMS [RFC5652], a previously distributed symmetric key-encryption 225 key can be used to encrypt a content-encryption key, which is in turn 226 used to encrypt the content. The key-encryption and content- 227 encryption algorithms are often different. If, for example, a 228 message content is encrypted with 128-bit AES key and the content- 229 encryption key is wrapped with a 256-bit AES key, then at most 128 230 bits of protection is provided. In this situation, the algorithm and 231 key size selections should ensure that the key encryption is at least 232 as strong as the content encryption. In general, wrapping one key 233 with another key of a different size yields the security strength of 234 the shorter key. 236 2.5. Opportunistic Security 238 Despite the guidance in Section 2.4, opportunistic security [RFC7435] 239 SHOULD also be considered, especially at the time a protocol 240 implementation is deployed and configured. While RSA with a 2048-bit 241 public key is quite a bit stronger than SHA-1, it is quite reasonable 242 to use them together if the alternative is no authentication 243 whatsoever. That said, the use of strong algorithms is always 244 preferable. 246 3. Algorithm Agility in Protocol Design 248 Some attempts at algorithm agility have not been completely 249 successful. This section provides some of the insights based on 250 protocol designs and deployments. 252 3.1. Algorithm Identifiers 254 If a protocol does not carry an algorithm identifier, then the 255 protocol version number or some other major change is needed to 256 transition from one algorithm to another. The inclusion of an 257 algorithm identifier is a minimal step toward cryptographic algorithm 258 agility. In addition, an IANA registry is needed to pair the 259 identifier with an algorithm specification. 261 Sometimes a combination of protocol version number and explicit 262 algorithm or suite identifiers is appropriate. For example, the TLS 263 version number names the default key derivation function and the 264 cipher suite identifier names the rest of the needed algorithms. 266 Sometimes application layer protocols can make use of transport layer 267 security protocols, such as TLS or DTLS. This insulates the 268 application layer protocol from the details of cryptography, but it 269 is likely to still be necessary to handle the transition from 270 unprotected traffic to protected traffic in the application layer 271 protocol. In addition, the application layer protocol may need to 272 handle the downgrade from encrypted communication to plaintext 273 communication. 275 3.2. Migration Mechanisms 277 Cryptographic algorithm selection or negotiation SHOULD be integrity 278 protected. If selection is not integrity protected, then the 279 protocol will be subject to a downgrade attack. Without integrity 280 protection of algorithm or suite selection, the attempt to transition 281 to a new algorithm or suite may introduce new opportunities for 282 downgrade attack. 284 If a protocol specifies a single mandatory-to-implement integrity 285 algorithm, eventually that algorithm will be found to be weak. 287 Extra care is needed when a mandatory-to-implement algorithm is used 288 to provide integrity protection for the negotiation of other 289 cryptographic algorithms. In this situation, a flaw in the 290 mandatory-to-implement algorithm may allow an attacker to influence 291 the choices of the other algorithms. 293 Performance is always a factor is selecting cryptographic algorithms. 294 In many algorithms, shorter keys offer higher performance, but less 295 security. Performance and security need to be balanced. Yet, all 296 algorithms age, and the advances in computing power available to the 297 attacker will eventually make any algorithm obsolete. For this 298 reason, protocols need mechanisms to migrate from one algorithm suite 299 to another over time, including the algorithm used to provide 300 integrity protection for algorithm negotiation. 302 3.3. Preserving Interoperability 304 Cryptographic algorithm deprecation is very hard. People do not like 305 to introduce interoperability problems, even to preserve security. 306 As a result, flawed algorithms are supported for far too long. The 307 impacts of legacy software an long support tails on security can be 308 reduced by making it easy to develop, deploy, and configure new 309 algorithms. 311 3.4. Cryptographic Key Management 313 Traditionally, protocol designers have avoided more than one approach 314 to key management because it makes the security analysis of the 315 overall protocol more difficult. When frameworks such as EAP and 316 GSSAPI are employed, the key management is very flexible, often 317 hiding many of the details from the application. This results in 318 protocols that support multiple key management approaches. In fact, 319 the key management approach itself may be negotiable, which creates a 320 design challenge to protect the negotiation of the key management 321 approach before it is used to produce cryptographic keys. 323 Protocols can negotiate a key management approach, derive an initial 324 cryptographic key, and then authenticate the negotiation. However, 325 if the authentication fails, the only recourse is to start the 326 negotiation over from the beginning. 328 Some environments will restrict the key management approaches by 329 policy. Such policies tend to improve interoperability within a 330 particular environment, but they cause problems for individuals that 331 need to work in multiple incompatible environments. 333 4. Cryptographic Algorithm Specifications 335 There are tradeoffs between the number of cryptographic algorithms 336 that are supported, time to deploy a new algorithm, and protocol 337 complexity. This section provides some of the insights about the 338 tradeoff faced by protocol designers. 340 4.1. Choosing Mandatory-to-Implement Algorithms 342 It seems like the ability to use an algorithm of one's own choosing 343 is very desirable; however, the selection is often better left to 344 experts. Further, any and all cryptographic algorithm choices ought 345 not be available in every implementation. Mandatory-to-implement 346 algorithms ought to be well studied, giving rise to significant 347 confidence. The selected algorithms need to be resistant to side- 348 channel attacks as well as meeting the performance, power, and code 349 size requirements on a wide variety of platforms. In addition, 350 inclusion of too many alternatives may add complexity to algorithm 351 selection or negotiation. 353 Sometime more than one mandatory-to-implement algorithm is needed to 354 increase the likelihood of interoperability among a diverse 355 population. For example, authenticated encryption is provided by 356 AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are 357 considered to be secure. AES-CCM is available in hardware used by 358 many small devices, and AES-GCM is parallelizable and well suited 359 high-speed devices. Therefore an application needing authenticated 360 encryption might specify one of these algorithms or both of these 361 algorithms, depending of the population. 363 4.2. Too Many Choices Can Be Harmful 365 It is fairly easy to specify the use of any arbitrary cryptographic 366 algorithm, and once the specification is available, the algorithm 367 gets implemented and deployed. Some people say that the freedom to 368 specify algorithms independently from the rest of the protocol has 369 lead to the specification of too many cryptographic algorithms. Once 370 deployed, even with moderate uptake, it is quite difficult to remove 371 algorithms because interoperability with some party will be impacted. 372 As a result, weaker ciphers stick around far too long. Sometimes 373 implementors are forced to maintain cryptographic algorithm 374 implementations well beyond their useful lifetime. 376 In order to manage the proliferation of algorithm choices and provide 377 an expectation of interoperability, many protocols specify mandatory- 378 to-implement algorithms or suites. All implementors are expected to 379 support the mandatory-to-implement cryptographic algorithm, and they 380 can include any others algorithms that they desire. The mandatory- 381 to-implement algorithms are chosen to be highly secure and follow the 382 guidance in RFC 1984 [RFC1984]. Of course, many other factors, 383 including intellectual property rights, have an impact on the 384 cryptographic algorithms that are selected by the community. 385 Generally, the mandatory-to-implement algorithms ought to be 386 preferred, and the other algorithms ought to be selected only in 387 special situations. However, it can be very difficult for a skilled 388 system administrator to determine the proper configuration to achieve 389 these preferences. 391 In some cases, more than one mandatory-to-implement cryptographic 392 algorithm has been specified. This is intended to ensure that at 393 least one secure cryptographic algorithm will be available, even if 394 other mandatory-to-implement algorithms are broken. To achieve this 395 goal, the selected algorithms must be diverse, so that a 396 cryptoanalytic advance against one of the algorithms does not also 397 impact the other selected algorithms. The idea is to have an 398 implemented and deployed algorithm as a fallback. However, all of 399 the selected algorithms need to be routinely exercised to ensure 400 quality implementation. This is not always easy to do, especially if 401 the various selected algorithms require different credentials. 402 Obtaining multiple credentials for the same installation is an 403 unacceptable burden on system administrators. Also, the manner by 404 which system administrators are advised to switch algorithms or 405 suites is at best ad hoc, and at worst entirely absent. 407 4.3. Picking One True Cipher Suite Can Be Harmful 409 After careful study and evaluation, the protocol designer could 410 select the one true cipher suite. Since algorithms age, such a 411 decision cannot be stable forever, so a version number is needed to 412 signal which algorithm that is being used. This has at least two 413 desirable consequences. First, the protocol is simpler since there 414 is no need for algorithm negotiation. Second, system administrators 415 do not need to make any algorithm-related configuration decisions. 416 However, the only way to respond to news that the an algorithm that 417 is part of the one true cipher suite has been broken is to update the 418 protocol specification to the next version, implement the new 419 specification, and then get it deployed. 421 The first IEEE 802.11 [WiFi] specification included the Wired 422 Equivalent Privacy (WEP) as the only encryption technique. WEP was 423 found to be quite weak [WEP], and a very large effort was needed to 424 specify, implement, and deploy the alternative encryption techniques. 426 Experience with the transition from SHA-1 to SHA-256 indicates that 427 the time from protocol specificate to widespread use takes more than 428 five years. In this case, the protocol specifications and 429 implementation were straightforward and fairly prompt. In many 430 software products, the new algorithm was not considered an update to 431 existing release, so the roll out of the next release, subsequent 432 deployment, and finally adjustment of the configuration by system 433 administrators took many years. In many consumer hardware products, 434 firmware to implement the new algorithm were difficult to locate and 435 install, or the were simply not available. Further, infrastructure 436 providers were unwilling to make the transition until all of their 437 potential clients were able to use the new algorithm. 439 4.4. National Cipher Suites 441 Some nations specify cryptographic algorithms, and then require their 442 use through legislation or regulations. These algorithms may not 443 have wide public review, and they can have limited reach of 444 deployments. Yet, the legislative or regulatory mandate creates a 445 captive market. As a result, the use of such algorithms get 446 specified, implemented, and deployed. The default server-side 447 configuration SHOULD disable such algorithms; in this way, explicit 448 action by the system administrator is needed to enable them where 449 they are actually required. 451 4.5. Balance Protocol Complexity 453 Protocol designers MUST be prepared for the supported cryptographic 454 algorithm set to change over time. As shown by the discussion in the 455 previous two sections, there is a spectrum of ways to enable the 456 transition. 458 Keep implementations as simple as possible. Complex protocol 459 negotiation provides opportunities for attack, such as downgrade 460 attacks. Support for many algorithm alternatives is also harmful, as 461 discussed in Section 4.1. Both of these can lead to portions of the 462 implementation that are rarely used, increasing the opportunity for 463 undiscovered exploitable implementation bugs. 465 5. Security Considerations 467 This document provides guidance to working groups and protocol 468 designers. The security of the Internet is improved when broken or 469 weak cryptographic algorithms can be easily replaced with strong 470 ones. 472 From a software development and maintenance perspective, 473 cryptographic algorithms can often be added and removed without 474 making changes to surrounding data structures, protocol parsing 475 routines, or state machines. This approach separates the 476 cryptographic algorithm implementation from the rest of the code, 477 which makes it easier to tackle special security concerns such as key 478 exposure and constant-time execution. 480 The situation is different for hardware, for both tiny devices and 481 very high-end data center equipment. Many tiny devices do not 482 include the ability to update the firmware at all. Even if the 483 firmware can be updated, tiny devices are often deployed in places 484 that make it very inconvenient to do so. High-end data center 485 equipment may use special-purpose chips to achieve very high 486 performance, which means that board-level replacement may be needed 487 to change the algorithm. Cost and down-time are both factors in such 488 an upgrade. 490 In most cases, the cryptographic algorithm remains strong, but an 491 attack is found against the way that the strong algorithm is used in 492 a particular protocol. In these cases, a protocol change will 493 probably be needed. For example, the order of cryptographic 494 operations in the TLS protocol has evolved as various attacks have 495 been discovered. Originally, TLS performed encryption after 496 computation of the message authentication code (MAC). This order of 497 operations is called MAC-then-encrypt, and it is no longer considered 498 secure [BN][K]. As a result, a mechanism was specified to use 499 encrypt-then-MAC instead [RFC7366]. Future versions of TLS are 500 expected to use exclusively authenticated encryption algorithms 501 [RFC5166], which should resolve the ordering discussion altogether. 502 After discovery of such attacks, updating the cryptographic 503 algorithms is not likely to be sufficient to thwart the new attack. 504 It may necessary to make significant changes to the protocol. 506 Some protocols are used to protected stored data. For example, 507 S/MIME [RFC5751] can protect a message kept in a mailbox. To recover 508 the protected stored data, protocol implementations need to support 509 older algorithms, even when they no longer use the older algorithms 510 for the protection of new stored data. 512 Support for too many algorithms can lead to implementation 513 vulnerabilities. When many algorithms are supported, some of them 514 will be rarely used. Any code that is rarely used can contain 515 undetected bugs, and algorithm implementations are no different. 517 Section 2.3 talks about algorithm transition without considering any 518 other aspects of the protocol design. In practice, there are 519 dependencies between the cryptographic algorithm and other aspects of 520 the protocol. For example, the BEAST attack [BEAST] against TLS 521 [RFC5246] caused many sites to turn off modern cryptographic 522 algorithms in favor of older and clearly weaker algorithms. 524 6. Normative References 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 530 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 531 April 2004. 533 7. Informative References 535 [BEAST] http://en.wikipedia.org/wiki/ 536 Transport_Layer_Security#BEAST_attack. 538 [BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: 539 Relations among notions and analysis of the generic 540 composition paradigm", Proceedings of AsiaCrypt '00, 541 Springer-Verlag LNCS No. 1976, p. 531, December 2000. 543 [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of 544 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 545 Special Publication 800-30D, November 2007. 547 [K] Krawczyk, H., "The Order of Encryption and Authentication 548 for Protecting Communications (or: How Secure Is SSL?)", 549 Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, 550 p. 310, August 2001. 552 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 553 Technology and the Internet", RFC 1984, August 1996. 555 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 556 (IKE)", RFC 2409, November 1998. 558 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 559 Engineering Task Force Standard Protocols", BCP 61, RFC 560 3365, August 2002. 562 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 563 CBC-MAC (CCM)", RFC 3610, September 2003. 565 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 566 2005. 568 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 569 RFC 4303, December 2005. 571 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", 572 RFC 4306, December 2005. 574 [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion 575 Control Mechanisms", RFC 5166, March 2008. 577 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 578 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 580 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 581 RFC 5652, September 2009. 583 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 584 Mail Extensions (S/MIME) Version 3.2 Message 585 Specification", RFC 5751, January 2010. 587 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm 588 Understanding in DNS Security Extensions (DNSSEC)", 589 RFC 6975, July 2013. 591 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security 592 (TLS) and Datagram Transport Layer Security (DTLS)", 593 RFC 7366, September 2014. 595 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most 596 of the Time", RFC 7435, December 2014. 598 [WEP] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy 600 [WiFi] IEEE , "Wireless LAN Medium Access Control (MAC) And 601 Physical Layer (PHY) Specifications, IEEE Std 802.11-1997, 602 1997. 604 Acknowledgements 606 Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon 607 Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, 608 Tony Finch, Ian Grigg, Peter Gutmann, Wes Hardaker, Joe Hildebrand, 609 Christian Huitema, Watson Ladd, Paul Lambert, Ben Laurie, Eliot Lear, 610 Nikos Mavrogiannopoulos, Yoav Nir, Rich Salz, Kristof Teichel, 611 Jeffrey Walton, Nico Williams, and Peter Yee for their review and 612 insightful comments. While some of these people do not agree with 613 some aspects of this document, the discussion that resulted for their 614 comments has certainly resulted in a better document. 616 Author's Address 618 Russ Housley 619 Vigil Security, LLC 620 918 Spring Knoll Drive 621 Herndon, VA 20170 622 USA 623 EMail: housley@vigilsec.com