RFC 7696
Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
📜 RFC 7696: Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms 💖
okay bestie, so this is the BCP (Best Current Practice, BCP 201 🎀) that's basically the IETF going "hey, if your protocol uses crypto, please make it able to switch algorithms later." 🦋 It's by R. Housley from Vigil Security, it's a Best Current Practice category, it was published in November 2015, and it's got ISSN 2070-1721 ✨. It doesn't obsolete or update anything, so it's a fresh start 🌸
The whole vibe is: crypto gets weaker over time, so protocols need a way to migrate, and that's the whole point of algorithm agility 💅
Abstract 🌸
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers have to support a common set of cryptographic algorithms for these to work, and this memo gives guidelines so protocols can migrate from one mandatory-to-implement algorithm suite to another over time 🔐
Status of This Memo 📝
This memo documents an Internet Best Current Practice.
This is an IETF product that represents the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741 🦋
The current status, any errata, and how to give feedback are at http://www.rfc-editor.org/info/rfc7696 ✨
Copyright Notice ⚖️
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please review these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 🎀
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Agility Guidelines . . . . . . . . . . . . . . . . . 3
2.1. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 4
2.2. Mandatory-to-Implement Algorithms . . . . . . . . . . . . 5
2.2.1. Platform Specifications . . . . . . . . . . . . . . . 5
2.2.2. Cryptographic Key Size . . . . . . . . . . . . . . . . 5
2.2.3. Providing Notice of Expected Changes . . . . . . . . . 6
2.3. Transitioning from Weak Algorithms . . . . . . . . . . . . 6
2.4. Algorithm Transition Mechanisms . . . . . . . . . . . . . 7
2.5. Cryptographic Key Management . . . . . . . . . . . . . . . 8
2.6. Preserving Interoperability . . . . . . . . . . . . . . . 8
2.7. Balancing Security Strength . . . . . . . . . . . . . . . 9
2.8. Balancing Protocol Complexity . . . . . . . . . . . . . . 10
2.9. Opportunistic Security . . . . . . . . . . . . . . . . . . 10
3. Cryptographic Algorithm Specifications . . . . . . . . . . . . 11
3.1. Choosing Mandatory-to-Implement Algorithms . . . . . . . . 11
3.2. Too Many Choices Can Be Harmful . . . . . . . . . . . . . 12
3.3. Picking One True Cipher Suite Can Be Harmful . . . . . . . 13
3.4. National Cipher Suites . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Normative References . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 191. Introduction 🌈
Lowkey the core problem is that a lot of IETF protocols use crypto for confidentiality, integrity, authentication, or digital signatures 🔐 Peers need a common set of algorithms, and usually a combo of compatible algorithms gets used to deliver the security you want. The set in use at any given time is called a cryptographic algorithm suite or cipher suite 💅 An algorithm identifier in a protocol can name one algorithm or a whole suite ✨
Here's the tea 🍵: crypto ages. As new cryptanalysis techniques show up and computers get faster, breaking an algorithm gets easier, which means more attackers can actually do it. We don't know how attacks will evolve, but they're definitely going to get better 😭 We don't know how much better or when. So protocol designers have to assume that faster computers or better cryptanalysis will eventually make any algorithm obsolete. That's why protocols need ways to migrate from one suite to another over time 💀
Algorithm agility is when a protocol can easily move from one suite to a more desirable one over time 🦋 For implementers, that means your implementation should be modular so new algorithms or suites can slot right in 🧩 Ideally you'd also have a way to measure when deployed implementations have actually moved off the old algorithms onto the better ones 📊 For designers, algorithm agility means you need one or more algorithm or suite identifiers, the set of mandatory-to-implement algorithms will change over time, and you'll need an IANA registry of algorithm identifiers 🎀
Identifiers alone won't get you easy migration though 🙈 People who maintain implementations and run services have to actually develop, deploy, and tweak configs to turn on the new algorithms and deprecate or disable the old ones. Honestly, it's been really hard for implementers and admins to remove or disable weak algorithms, mostly because of interoperability worries 😩 Legacy systems and resource-constrained devices that can't handle new algorithms make it worse. So people end up living with weaker algorithms, sometimes seriously broken ones, long after experts say to migrate 💔
1.1. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. ✨
2. Algorithm Agility Guidelines 🎀
These guidelines are for IETF working groups and protocol authors building IETF protocols that use crypto algorithms 🫶 Past attempts at algorithm agility haven't been totally successful, so this section shares some lessons from them 📝
2.1. Algorithm Identifiers 🏷️
IETF protocols that use cryptographic algorithms "MUST" support one or more algorithms or suites. The protocol "MUST" include a mechanism to identify the algorithm or suite being used. An algorithm identifier can be carried explicitly in the protocol. Or a management mechanism can identify the algorithm instead. For example, a key table entry that has a key value and an algorithm identifier might be enough 🔑
If a protocol doesn't carry an algorithm identifier, you need a protocol version number or some other major change to move from one algorithm to another. Including an algorithm identifier is a small but real step toward agility 🌸
Sometimes you want a combo of a protocol version number and explicit algorithm or suite identifiers. For example, the Transport Layer Security (TLS) [RFC5246] version number names the default key derivation function, and the cipher suite identifier names the rest of the algorithms 🔐
Some approaches carry one identifier per algorithm used. Others carry one identifier for a full suite. Both show up in IETF protocols 🧩 Designers are encouraged to pick one approach and stick with it across the protocol or family of protocols 💅 Suite identifiers make it easier for the designer to make sure algorithm choices are complete and compatible for future assignments. The catch is that suite identifiers face a combinatoric explosion as new algorithms get defined 💀 Algorithm identifiers, on the other hand, put a burden on implementations because they force a run-time decision about which algorithm combinations are acceptable 😵💫
Whichever approach you use, protocols have historically negotiated the symmetric cipher and cipher mode together, so they stay compatible ✨
In the IPsec protocol suite, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the Authentication Header (AH) [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. That separation is a completely fine design choice 🦋 TLS [RFC5246] carries cipher suite identifiers instead, which is also a completely fine design choice 🎀
An IANA registry "SHOULD" be used for these algorithm or suite identifiers. Once an algorithm identifier is in the registry, it "should not" be changed or removed. It is desirable, though, to mark a registry entry as deprecated when implementing it is no longer advisable 🪦
2.2. Mandatory-to-Implement Algorithms 🔥
For secure interoperability, BCP 61 [RFC3365] recognizes that peers using crypto mechanisms have to support a common set of strong cryptographic algorithms. So IETF protocols that use cryptography "MUST" specify one or more strong mandatory-to-implement algorithms or suites. That doesn't mean every deployment has to use that algorithm or suite, but it does mean it has to be available to all deployments 💖
The IETF needs to be able to change the mandatory-to-implement algorithms over time, and it's really desirable to do that without updating the base protocol spec 🙌 To make that happen, it is "RECOMMENDED" that the base protocol specification include a reference to a companion algorithms document. That way you can update one document without necessarily updating the other. This split also helps the base protocol move up the standards maturity ladder even when the algorithms document changes a lot 🪜
The IETF "SHOULD" keep the set of mandatory-to-implement algorithms small. Because of that, the set will inevitably change over time, and the transition "SHOULD" happen before the algorithms in the current set weaken to the breaking point ⏳
That's the end of part 1! 🌈 Part 2 is coming next, bestie, stay tuned 💜
2.2.1. Platform Specifications
okay so bestie, quick heads up 🫶 the mandatory-to-implement picks are NOT set for protocols that are embedded inside other protocols 💅 instead, the system-level spec is the one that names the MTI algorithm or suite ✨ like, S/MIME [RFC5751] uses the cryptographic message Syntax (CMS) [RFC5652], and S/MIME is the one that picks the MTI algorithms, not CMS 🎀 this is lowkey genius because other protocols can totally reuse CMS and make their own MTI choices 🦋
2.2.2. Cryptographic Key Size
no cap, some algorithms are basically glued to one key size 🔒 but others are super flexible with lots of sizes 🌈 same deal with parameters like integrity check values or nonces 🧚 the algorithm spec MUST identify the exact key sizes and parameter sizes that are supported 💖 and when more than one key size is available, expect the MTI key size to go up over time 📈 that's the glow-up era 👑
for asymmetric keys, go check out BCP 86 [RFC3766] 💜
for symmetric keys, BCP 195 [RFC7525] is your bestie 🌸
2.2.3. Providing Notice of Expected Changes
ngl, algorithms rarely die without warning 💀 it's usually more about age 🕰️ like, DES went to Triple-DES went to AES over decades, and symmetric block cipher strength went from 56 bits to 112 bits to 128 bits 🌸 so where possible, authors SHOULD provide notice to implementers about expected algorithm transitions 🔥
one approach first used in RFC 4307 [RFC4307] is using SHOULD+, SHOULD-, and MUST- when specifying algorithms ✨ these definitions are slightly modified from RFC 4307, so here's the tea:
- SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted to a MUST in the future. 💖
- SHOULD- This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD- will be deprecated to a MAY or worse in the future. 🥀
- MUST- This term means the same as MUST. However, it is expected that an algorithm marked as MUST- will be downgraded in the future. Although the status of the algorithm will be determined at a later time, it is reasonable to expect that a the status of a MUST- algorithm will remain at least a SHOULD or a SHOULD-. 🦋
2.3. Transitioning from Weak Algorithms
okay so transitioning off a weak algorithm can be kinda tricky 😭 switching TO a new, better algorithm is easy peasy 🍓 and once the new one is everywhere, the old one ought no longer be used 🌷 BUT knowledge about how the new algorithm gets implemented and deployed is always a little imperfect, so you can't be totally sure it'll interoperate 🙈
algorithm transition is naturally helped along by an algorithm selection or negotiation mechanism 🤝 protocols usually pick the best algorithm or suite that ALL the communicating peers support and that fits their policies 💅 also, you need a way to figure out whether the new algorithm has actually been deployed 👀 for example, SMIMECapabilities [RFC5751] lets S/MIME mail user agents share their list of algorithms in preference order 💌 and the DNSSEC EDNS0 option [RFC6975] measures how much new digital signing algorithms are being accepted and used 📊
in the Resource Public Key Infrastructure (RPKI), you need a globally recognized digital signature 🌍 BCP 182 [RFC6916] gives an approach where a second signature algorithm gets introduced first, and then the original one is phased out 🦋
in the worst case, the old algorithm turns out to be tragically flawed 😱 like, a casual attacker can download a simple script and break it 💀 sadly this has happened when a secure algorithm gets used incorrectly or with poor key management, which leaves a weak cryptographic algorithm suite behind 😭 in those situations the protection is severely compromised, maybe to the point where you want to stop using the weak suite altogether 🚫 and you reject offers to use it well before the new suite is widely deployed 🙅♀️
anyway, there comes a point where you refuse the old, weak algorithm or suite no matter what 🛑 this can happen on a flag day 🚩 or each installation can pick its own date 🗓️
2.4. Algorithm Transition Mechanisms
okay bestie, the big rule here: cryptographic algorithm selection or negotiation SHOULD be integrity protected 🔐 if it isn't, the protocol is open to a downgrade attack 😈 and without integrity protection on algorithm or suite selection, trying to transition to a new algorithm can actually create new openings for downgrade attacks 🥺
transition mechanisms need to consider the algorithm used to provide integrity protection for the negotiation itself 🧠
if a protocol specifies a single mandatory-to-implement integrity algorithm, eventually that algorithm will be found to be weak 💔 it's inevitable, sorry 🫠
extra care is needed when a mandatory-to-implement algorithm is used to integrity protect the negotiation of other cryptographic algorithms 🚨 in this situation, a flaw in the MTI algorithm could let an attacker influence the choices of the other algorithms 😱
2.5. Cryptographic Key Establishment
historically, protocol designers avoided having more than one approach for exchanges that establish cryptographic keys 🙃 because it makes the security analysis of the whole protocol way harder 🥵 but when frameworks like the Extensible Authentication Protocol (EAP) [RFC3748] and Simple Authentication and Security Layer (SASL) [RFC4422] are used, key establishment gets super flexible and usually hides most of the details from the application 🪄 which means protocols end up supporting multiple key establishment approaches 🌈 and actually, the key establishment approach itself can be negotiated, which is a design challenge: you have to protect the negotiation of that approach before it's used to produce cryptographic keys 🔑
protocols can negotiate a key establishment approach, derive an initial cryptographic key, and then authenticate the negotiation 🫶 however, if the authentication fails, the only recourse is to start the negotiation over from the beginning 😩
some environments restrict the key establishment approaches by policy 📜 those policies tend to improve interoperability inside one particular environment 🏠 but they cause problems for people who need to work across multiple incompatible environments 🥲
2.6. Preserving Interoperability
okay real talk, cryptographic algorithm deprecation is SO hard 😮💨 people really don't like introducing interoperability problems, even if it's for security 🙄 so flawed algorithms stick around for way too long 🕰️ the impact of legacy software and long support tails on security can be reduced by making it easy to move from old algorithms and suites to new ones 🛤️ and honestly, social pressure is often needed to make the transition actually happen 📣
implementers have been reluctant to remove deprecated algorithms or suites from server software 🙈 and server admins have been reluctant to disable them, worried that some party won't be able to connect to their server anymore 😬 implementers and admins want better security by using the best supported algorithms, but they're also trying to keep connectivity 🔗 recently, some browser vendors started showing visual warnings when a deprecated algorithm or suite is used ⚠️ those warnings give a fresh incentive to move away from deprecated algorithms and suites, and they prompt customers to ask for better security 🙋♀️
transition in Internet infrastructure is especially rough 😵💫 the digital signature on the certificate for an intermediate certification authority (CA) [RFC5280] is often expected to last decades 🗓️ which makes it hard to move away from a weak signature algorithm or short key length 🧱 once a long-lived certificate is issued with a particular signature algorithm, many relying parties use that algorithm, and none of them can stop supporting it without invalidating all of the subordinate certificates 💥 in a hierarchical system, many subordinate certificates could be impacted by dropping support for a weak signature algorithm or its associated hash function 🌳
organizations with a lot of influence can help by coordinating the demise of an algorithm suite 🤝 which makes the transition easier for their own users and for everyone else too 💜
2.7. Balancing Security Strength
when you're selecting or negotiating a suite of cryptographic algorithms, the strength of each algorithm SHOULD be considered ⚖️ the algorithms in a suite SHOULD be roughly equal, with comparable best-known attack work factors 💪 but the security service each algorithm provides in a particular context also needs to be considered when making the pick 🎯 algorithm strength needs to be considered when a protocol is designed, and again when a protocol implementation is deployed and configured 🛠️ expert advice is useful, but honestly it's often unavailable to the sysadmins actually deploying the thing 😓 so for this reason, protocol designers SHOULD provide clear guidance to implementers, so balanced options are available at deployment time 📘
performance is always a factor in selecting cryptographic algorithms 🏎️ performance and security need to be balanced ⚖️ some algorithms are flexible in strength by adjusting the key size, number of rounds, authentication tag size, prime group size, and so on 🎚️ for example, TLS cipher suites include Diffie-Hellman or RSA without specifying a particular public key length 🔐 if the algorithm identifier or suite identifier named a particular public key length, migrating to longer ones would be harder 🧗♀️ on the other hand, including a public key length would make it easier to move away from short ones when the computational resources available to an attacker make that necessary 🏃♀️ the flexibility on asymmetric key length has caused interoperability problems, so to avoid them in the future, any aspect of the algorithm not specified by the algorithm identifiers needs to be negotiated, including key size and parameters 🤓
in CMS [RFC5652], a previously distributed symmetric key-encryption key can be used to encrypt a content-encryption key, which then encrypts the content 📦 the key-encryption and content-encryption algorithms are often different 🔀 if, for example, message content is encrypted with a 128-bit AES key but the content-encryption key is wrapped with a 256-bit AES key, then at most 128 bits of protection is provided 😬 in this situation, the algorithm and key size selections should ensure the key encryption is at least as strong as the content encryption 💪 generally speaking, wrapping one key with another key of a different size yields the security strength of the shorter key 🥺✨
2.8. Balancing Protocol Complexity ✨
Okay bestie, protocol designs have to plan ahead for the fact that the set of supported crypto algorithms will change over time 🔄 There are a bunch of ways to make that transition happen, and Section 3 spills the tea on some of the related issues 💅
Keep implementations as simple as possible 🫶 Complex protocol negotiation opens the door to attacks, like downgrade attacks, and that's literally the last thing we want 😭 Supporting a ton of algorithm alternatives is also a problem. Both of these things can leave parts of the implementation that almost nobody uses, and those dusty corners are where undiscovered, exploitable bugs love to hide 🙈
2.9. Opportunistic Security 🦋
Okay, I know Section 2.4 just said what it said, but opportunistic security [RFC7435] is also worth thinking about, especially when a protocol implementation gets deployed and configured 🌸 Like with any other reason for encrypting traffic, opportunistic security needs to use the strongest encryption algorithms that are implemented and allowed by policy 💜 When the communicating parties don't have strong algorithms in common, using algorithms that are weak against advanced attackers but still good enough against everyone else is one way to make pervasive surveillance way harder 🕵️♀️ So, when the parties don't have strong algorithms in common, algorithms that wouldn't be acceptable in lots of negotiated situations are fine for opportunistic security, as long as legacy systems are in use for unauthenticated encrypted sessions (as discussed in Section 3 of [RFC7435]) and their use doesn't make downgrade attacks easier 🙏 Weaker algorithms and shorter key sizes are also acceptable for opportunistic security, with the same constraints 🎀
Not to be dramatic, but the same constraints apply every single time. Downgrade attacks are a hard no 💀
That said, using strong algorithms is always preferable ✨👑
3. Cryptographic Algorithm Specifications 🌈
Okay so there are tradeoffs between how many cryptographic algorithms a protocol supports and how long it takes to deploy a new one 🧠 This section shares some of the insights protocol designers have to juggle when they deal with that tradeoff 🍓
Ideally, two independent sets of mandatory-to-implement algorithms get specified, which gives you a primary suite and a secondary suite 🫶 This approach makes sure the secondary suite is already widely deployed if a flaw turns up in the primary one 🛟
3.1. Choosing Mandatory-to-Implement Algorithms 💅
It might feel like being able to pick whatever algorithm you want would be super desirable, but honestly, the selection is usually better left to experts 🧑🔬 When there are choices, end-users can pick between configuration profiles that experts have already defined 🎀 Also, experts don't need to specify every single cryptographic algorithm alternative 🙅♀️ Specifying all the possible choices won't make them all show up in every implementation, so it's not a magic fix 😭
Mandatory-to-implement algorithms MUST have a stable public specification and public documentation that's been well studied, so people can feel really confident about them 🔍 The IETF has always loved unencumbered algorithms 🕊️ There are big benefits to choosing algorithms and suites that are widely deployed 📈 The chosen algorithms also need to resist side-channel attacks and still meet the performance, power, and code size needs across a wide variety of platforms 🔋 Including too many alternatives can make algorithm selection or negotiation more complicated 🌀 Specifying too many alternatives will likely hurt interoperability, and it might hurt security too 💔 When someone is specifying new algorithms or suites, it's smart of them to think about whether existing ones can be deprecated 🧹
There's a lot of value in picking the same algorithms and suites across different protocols 💖 Using the same algorithms can make things simpler when more than one of these protocols runs on the same device or system 🧩
Sometimes you need more than one mandatory-to-implement algorithm to make interoperability more likely across a diverse crowd 🌍 For example, authenticated encryption is provided by AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these are considered secure, no cap 🔐 AES-CCM shows up in hardware on lots of small devices, and AES-GCM is parallelizable and super well suited to high-speed devices ⚡ So an application that needs authenticated encryption might specify one of these algorithms, or both, depending on who's in the population 🥰
3.2. Too Many Choices Can Be Harmful 🙃
It's pretty easy to specify the use of any arbitrary cryptographic algorithm, and once the spec exists, the algorithm gets implemented and deployed 🚀 Some people say the freedom to specify algorithms separately from the rest of the protocol has led to way too many cryptographic algorithms existing 📚 Once something is deployed, even with only moderate uptake, it's really hard to remove the algorithm, because interoperability with some party will get impacted 😩 As a result, weaker ciphers stick around far too long 🕰️ Sometimes implementers are stuck maintaining cryptographic algorithm implementations long after they've outlived their useful lifetime 🪦
To manage the proliferation of algorithm choices and give everyone an expectation of interoperability, lots of protocols specify mandatory-to-implement algorithms or suites 🤝 Every implementer is expected to support the mandatory-to-implement cryptographic algorithm, and they can include any other algorithms they want 🎨 The mandatory-to-implement algorithms are chosen to be highly secure and to follow the guidance in RFC 1984 [RFC1984] 🛡️ Of course, plenty of other factors, including intellectual property rights, affect which cryptographic algorithms the community ends up selecting ⚖️ Generally, the mandatory-to-implement algorithms ought to be preferred, and the other algorithms ought to be picked only in special situations 🌟 Still, it can be super difficult for even a skilled system administrator to figure out the proper configuration to achieve those preferences 🥲
In some cases, more than one mandatory-to-implement cryptographic algorithm has been specified 💫 The goal is to make sure at least one secure cryptographic algorithm is still available, even if the other mandatory-to-implement algorithms get broken 🧯 To get there, the selected algorithms must be diverse, so that a cryptanalytic advance against one of them doesn't also hit the others 🌈 The whole idea is to have an implemented and deployed algorithm ready as a fallback 🪂 All of the selected algorithms also need to be routinely exercised to make sure the implementation stays high quality 🏋️♀️ That isn't always easy, especially when the different selected algorithms need different credentials 🔑 Getting multiple credentials for the same installation is an unacceptable burden on system administrators 😤 And honestly, the way system administrators get advised to switch algorithms or suites is, at best, ad hoc, and at worst, totally absent 🫠
3.3. Picking One True Cipher Suite Can Be Harmful 👑
In the past, protocol designers chose one cryptographic algorithm or suite and then tied a bunch of protocol details to that choice 🧵 You need to plan for algorithm transition, either because a mistake got made in the initial selection, or because the protocol gets used successfully for a long time and the algorithm gets weak with age ⏳ Either way, the design should make transition possible 🔓
Protocol designers sometimes get misled by how simple things look when you pick one true algorithm or suite 🥺 Since algorithms age, the selection can't stay stable forever 📉 Even the simplest protocol needs a version number to signal which algorithm is being used 🔢 This approach has at least two good consequences 💕 First, the protocol is simpler, because there's no need for algorithm negotiation 🪄 Second, system administrators don't have to make any algorithm-related configuration decisions 😌 But the only way to respond to news that an algorithm in the one true cipher suite has been broken is to update the protocol specification to the next version, implement that new specification, and then get it deployed 🚚 Not me having to wait for all of that 😭
The first IEEE 802.11 [WiFi] specification included Wired Equivalent Privacy (WEP) as its only encryption technique 📶 Lots of the protocol details were driven by that selected algorithm 🧩 WEP was found to be quite weak [WEP], so a very large effort was needed to specify, implement, and deploy the alternative encryption techniques 😵 That effort got even harder because of the protocol design choices tied to the initial algorithm selection, plus the desire for backward compatibility 🥴
Experience with the transition from SHA-1 to SHA-256 shows that the time from protocol specification to widespread use takes more than five years ⏰ In this case, the protocol specifications and implementation were straightforward and fairly prompt 🏃♀️ But in many software products, the new algorithm wasn't considered an update to the existing release, so rolling out the next release, deploying it, and finally having system administrators adjust the configuration took many years 🐢 In many consumer hardware products, firmware to implement the new algorithm was hard to find and install, or it simply wasn't available 📦 Infrastructure providers were also unwilling to make the transition until all of their potential clients could use the new algorithm 🙄
3.4. National Cipher Suites 🌍
Some nations specify cryptographic algorithms and then require their use through legislation or regulations 🏛️ These algorithms may not have had wide public review, and they can have limited geographic scope in their deployment 🗺️ Still, the legislative or regulatory mandate creates a captive market 🔒 So these algorithms get specified, implemented, and deployed anyway 🚢 The default server or responder configuration SHOULD disable such algorithms, which means explicit action by the system administrator is needed to enable them where they're actually required 🛑 For tiny devices with no user interface, an administrator action may only be possible at the time the device is purchased 🛒
National algorithms can force an implementer to produce several incompatible product releases for different countries or regions 🌏 That costs significantly more than developing a product using a globally acceptable algorithm 💸 It could get even worse if the various national algorithms impose different requirements on the protocol, its key management, or its use of random values 🎲😩
4. Security Considerations 🔐✨
Okay bestie, this section is literally the reason this whole doc exists 💖. It's guidance for working groups and protocol designers, and the Internet gets way safer when broken or weak crypto algorithms can be easily swapped out for strong ones 🔥.
From a software dev and maintenance pov, crypto algorithms can often be added and removed without changing the surrounding data structures, protocol parsing routines, or state machines 🧚. That keeps the crypto algorithm implementation separate from the rest of the code, which makes it so much easier to handle special security stuff like key exposure and constant-time execution 💅.
Sometimes app-layer protocols can lean on transport-layer security protocols like TLS [RFC5246] or Datagram TLS (DTLS) [RFC6347] 🫶. That shields the app-layer protocol from the nitty-gritty of crypto, but it's still likely necessary to handle the switch from unprotected traffic to protected traffic in the app-layer protocol itself 🌸. The app-layer protocol may also need to handle a downgrade from encrypted communication to plaintext 🙈.
Hardware is a whole mess for algorithm transitions, for both tiny devices and super high-end data center gear 💀. Lots of tiny devices don't have the ability to update firmware at all 😭. Even when firmware can be updated, tiny devices are often deployed somewhere that makes updating super inconvenient 🍓. High-end data center equipment may use special-purpose chips to hit very high performance, which means board-level replacement might be needed to change the algorithm 👑. Cost and downtime are both factors in an upgrade like that 🥲.
In most cases the crypto algorithm is still strong, but an attack is found against the way that strong algorithm gets used in a particular protocol 🦋. In those cases, a protocol change will probably be needed 🔧. For example, the order of crypto operations in TLS has evolved as various attacks got discovered. Originally, TLS did encryption after computing the message authentication code (MAC) 🫠. That order is called MAC-then-encrypt, which actually involves MAC computation, padding, and then encryption, and it's no longer considered secure [BN] [K] 😭. So a mechanism was specified to use encrypt-then-MAC instead [RFC7366] ✨. Future versions of TLS are expected to use exclusively authenticated encryption algorithms [RFC5116], which should resolve the ordering discussion altogether 💜. After attacks like these are discovered, updating the cryptographic algorithms isn't likely to be enough to stop the new attack. It may be necessary to make significant changes to the protocol itself 😬.
Some protocols are used to protect stored data. For example, S/MIME [RFC5751] can protect a message kept in a mailbox 📬. To recover that protected stored data, protocol implementations need to support older algorithms, even when they no longer use the older algorithms to protect new stored data 🗄️.
Supporting too many algorithms can lead to implementation vulnerabilities 🙅♀️. When many algorithms are supported, some of them will be rarely used. Any rarely used code can hide undetected bugs, and algorithm implementations are no different 🐛. Measurements SHOULD be used to determine whether implemented algorithms are actually being used, and if they're not, future releases should remove them. Also, unused algorithms or suites SHOULD be marked as deprecated in the IANA registry. Short version: eliminate the cruft 🧹✨.
Section 2.3 talks about algorithm transition without considering any other aspects of the protocol design. In practice, though, there are dependencies between the cryptographic algorithm and other parts of the protocol 🔗. For example, the BEAST attack [BEAST] against TLS [RFC5246] caused many sites to turn off modern cryptographic algorithms in favor of older, clearly weaker ones 💀.
Mechanisms for timely update of devices are needed to deploy a replacement algorithm or suite ⏰. It takes a long time to specify, implement, and deploy a replacement, so the transition process needs to begin when practically exploitable flaws become known. Update processes on some devices involve certification, which adds even more time to deploy a replacement 📋. For example, devices that are part of health or safety systems often require certification before deployment 🏥. Embedded systems and SCADA (supervisory control and data acquisition) systems often have upgrade cycles stretching over many years, which leads to similar time-to-deployment issues 🕰️. Prompt action is needed if a replacement has any hope of being deployed before exploitation techniques become widely available 🚨.
5. IANA Considerations 🗂️
This document does not establish any new IANA registries, nor does it add any entries to existing registries.
This document does RECOMMEND a convention for new registries for cryptographic algorithm or suite identifiers. Once an algorithm or suite identifier is added to the registry, it SHOULD NOT be changed or removed. That said, it's desirable to include a means of marking a registry entry as deprecated when implementation is no longer advisable 🏷️💖.
6. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
DOI 10.17487/RFC3766, April 2004,
<http://www.rfc-editor.org/info/rfc3766>.7. Informative References 📚✨
okay bestie, these are the extra reads 🤓 not required for the core spec, but they're the receipts behind the vibes. Every single one is listed below exactly as written so you can go hunting 🔍💜
[BEAST] Wikipedia, "BEAST attack" under "Transport Layer Security",
November 2015, <https://en.wikipedia.org/w/index.php?title=
Transport_Layer_Security&oldid=689441642#BEAST_attack>.
[BN] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among notions and analysis of the generic
composition paradigm", Proceedings of AsiaCrypt '00,
Springer-Verlag LNCS No. 1976, p. 531,
DOI 10.1007/3-540-44448-3_41, December 2000.
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-30D, November 2007.
[K] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (or: How Secure Is SSL?)",
Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139,
p. 310, DOI 10.1007/3-540-44647-8_19, August 2001.
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
Technology and the Internet", BCP 200, RFC 1984,
DOI 10.17487/RFC1984, August 1996,
<http://www.rfc-editor.org/info/rfc1984>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, DOI 10.17487/RFC3365, August 2002,
<http://www.rfc-editor.org/info/rfc3365>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
DOI 10.17487/RFC4307, December 2005,
<http://www.rfc-editor.org/info/rfc4307>.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<http://www.rfc-editor.org/info/rfc4422>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
2013, <http://www.rfc-editor.org/info/rfc6916>.
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm
Understanding in DNS Security Extensions (DNSSEC)",
RFC 6975, DOI 10.17487/RFC6975, July 2013,
<http://www.rfc-editor.org/info/rfc6975>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)",
RFC 7366, DOI 10.17487/RFC7366, September 2014,
<http://www.rfc-editor.org/info/rfc7366>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most
of the Time", RFC 7435, DOI 10.17487/RFC7435, December
2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations
for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)", BCP 195,
RFC 7525, DOI 10.17487/RFC7525, May 2015,
<http://www.rfc-editor.org/info/rfc7525>.
[WEP] Wikipedia, "Wired Equivalent Privacy", November 2015,
<https://en.wikipedia.org/w/index.php?
title=Wired_Equivalent_Privacy&oldid=688848497>.
[WiFi] IEEE, "Wireless LAN Medium Access Control (MAC) And
Physical Layer (PHY) Specifications", IEEE Std 802.11-1997,
1997.Acknowledgements 🫶🌸
big group hug 🥹💖 to everyone who reviewed this and dropped comments that made it so much better: Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, Tony Finch, Ian Grigg, Peter Gutmann, Phillip Hallam-Baker, Wes Hardaker, Joe Hildebrand, Paul Hoffman, Christian Huitema, Leif Johansson, Suresh Krishnan, Watson Ladd, Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Kathleen Moriarty, Yoav Nir, Kenny Paterson, Rich Salz, Wendy Seltzer, Joel Sing, Rene Struik, Kristof Teichel, Martin Thompson, Jeffrey Walton, Nico Williams, and Peter Yee 👑✨
Not everyone on that list agreed with every single choice in the doc 🙈, but the debate they sparked is exactly why it turned out this strong. Healthy disagreement = a better spec, periodt 💅💜
Author's Address 🎀
Russ Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
United States
Email: housley@vigilsec.com📦 where this page comes from
- ietf: rfc7696 2015-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms