RFC 9150

📜 TLS 1.3 Authentication and Integrity-Only Cipher Suites 🎀

okay bestie, so this is an Informational RFC 💅 (it is NOT a Standards Track thing, so no cap, it's not an official must-follow spec 🙈). It's from the Independent Submission stream, written by N. Cam-Winget (Cisco Systems ☁️) and J. Visoky (ODVA 🏭). It came out in April 2022 and its number is RFC 9150 ✨. It doesn't obsolete anything and doesn't update anything either, so it's a fresh one 🌸.

Part 1 of 3 covers the abstract, status, copyright, the table of contents, and the intro plus terminology. Let's go 🫶

---

Abstract ✨

okay so this doc defines some TLS 1.3 cipher suites built on HMAC 🔐. The vibe here is authentication and integrity, but no confidentiality 🙅‍♀️. You still get server authentication and, if you want it, mutual authentication, plus data authenticity. The catch is these suites are not for everyday use 💀. They fit IoT and constrained environments where nobody needs the messages kept secret, but integrity, server auth, and optional client auth still matter a lot 🧚.

The doc gives examples of those use cases, but here's the big warning 🚨: before you touch these integrity-only suites, you NEED a threat model for your situation, and you need to run a threat analysis inside that model to see if they're even appropriate. The IETF doesn't endorse this approach and it doesn't have IETF consensus 😬. It's just written down so people can implement a reduced-security mechanism that does authentication and message integrity without confidentiality, and they can interoperate 🦋.

⚠️ bestie, read that last bit twice. Integrity-only is a reduced-security option, not a default.

---

Status of This Memo 📝

okay this part is pretty chill. This document is not an Internet Standards Track spec, it's published just for information 💖. It's a contribution to the RFC Series, separate from any other RFC stream, and the RFC Editor published it at their discretion without saying whether it's good to implement or deploy 🤷‍♀️. Anything the RFC Editor approves for publication isn't eligible for any level of Internet Standard, and you can check Section 2 of RFC 7841 for the details 🎀.

You can find the current status, errata, and feedback info at https://www.rfc-editor.org/info/rfc9150 🌈.

---

Copyright Notice 💜

Copyright (c) 2022 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 (https://trustee.ietf.org/license-info) as they were on the publication date. Read those carefully, bestie, because they explain your rights and restrictions for this doc 📜.

---

Table of Contents 🗂️

1.  Introduction
2.  Terminology
3.  Applicability Statement
4.  Cryptographic Negotiation Using Integrity-Only Cipher Suites
5.  Record Payload Protection for Integrity-Only Cipher Suites
6.  Key Schedule when Using Integrity-Only Cipher Suites
7.  Error Alerts
8.  IANA Considerations
9.  Security and Privacy Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

---

1. Introduction 🦋

okay so there are a bunch of use cases where privacy isn't really the main concern, but authenticity of the transport is SUPER important 😭. Like in industrial automation, you could have TCP or UDP traffic telling a robotic arm how far to move and how fast 🤖. If an attacker can tamper with those packets, they could change the arm's movement and maybe cause physical damage 💀. Motion control commands usually aren't considered sensitive though, so there's no requirement for confidentiality there. Another IoT example is weather reporting 🌦️. Confidentiality isn't a must, but the message still needs authenticity so nobody can mess with its integrity 🫶.

Now, there's no requirement to encrypt messages where the info isn't confidential. Think no intellectual property involved in the process, or a threat model that doesn't include outsider attacks (like a closed system) 🔒. BUT, and this is a big but 💅, it doesn't apply the same way to every use case. A robotic arm might run a process with no IP in one setting and a process WITH IP in another. So a user or system developer really needs to look carefully at both how sensitive the data is and the threat model, to decide if encryption is needed before deploying equipment and protections 🧐.

Also, lots of these systems need low latency ⚡ and several IoT devices have limited processing power 🪫. But these IoT systems still benefit a LOT from TLS 1.3 for secure comms ✨. Since they don't need as much confidentiality, this document describes TLS 1.3 cipher suites [RFC8446] that keep data integrity without confidentiality 🎀. These aren't for general use, because they don't meet TLS's confidentiality and privacy goals 🙈. They should only be used where confidentiality and privacy aren't a concern AND there are constraints that stop you from using cipher suites with the full set of security properties 💖.

Same disclaimer again 📢: the IETF doesn't endorse this approach and it doesn't have IETF consensus. It's presented so implementers can build an interoperable, reduced-security mechanism that gives authentication and message integrity, with confidentiality supported 💜.

⚠️ hold up, the original says "with supporting confidentiality" at the end of this paragraph, which reads like a typo in the source. Keep it as written when you check the spec 🧐.

---

2. Terminology 📚

okay so this section is about the normative language 💅. The document follows the conventions for normative language so implementers get clear instructions 🌸. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but ONLY when they appear in all capitals, exactly like that 🔥.

---

Part 1 of 3 done 🎀 Send "part 2" when you're ready for Section 3 onward, bestie 🫶

3. Applicability Statement 🦋

okay so this section is basically "when is it actually fine to skip encryption?" 🧐 The two cipher suites in this doc are built on HMAC SHAs [RFC6234], and they're meant for a small, specific group of apps where confidentiality can chill out and the goal is to keep the number of crypto algorithms as low as possible 💅. Let's go through the use cases!

Industrial automation needs data integrity a LOT, but it usually doesn't need the messages to be private 🤖. Think of a robotic arm that paints car bodies in a factory. It's one piece of a bigger multi-step line, and its movements probably aren't a trade secret or sensitive IP ✨. Some other parts of making the car might be super secret though! And the paint mix itself might be confidential, but that gets mixed by a totally different machine, so you can encrypt that link without also encrypting the robot's link 🎨. Factories have segmented equipment with different risk levels for IP, but almost every message still needs strong data authenticity 🔒.

Next up is fine-grained time updates, which are closely related 🕰️. Motion systems lean on time sync to run properly. Time updates are basically public info, so an attacker knowing the time isn't a threat 🙈. Rarely, if ever, does time info create a serious privacy attack surface. The authenticity still matters a ton though 😭. If someone maliciously changes time data, the fallout could be anything from denial of service to actual physical damage, depending on the situation and what the attacker can do 💀. And since these updates are super fine-grained, latency needs to be very low 🏃‍♀️.

Third, we have alarm data 🚨. Industrial sensing gear can be set up to send alarms when conditions are met, like temperature going above or below a threshold ("the temp is too hot!!"). That data helps operators or automated systems catch out-of-tolerance conditions and fix stuff 🛠️. Again, reading it usually doesn't hand an attacker anything useful. It's mostly just the physical state of the system 🌡️. BUT if an attacker can modify it, they could trigger false alarms or hide evidence of their own attack, which is a whole disaster 😱. Sensors are also often low-powered and cost-sensitive, so they might not have enough processing power for encryption 🪫. Sending data that's authenticated but not encrypted takes pressure off those devices and still protects against tampering 🛡️. If someone wants encryption, they can pay for a sensor that has it, but for plenty of folks, authenticity is enough 💜.

The fourth use case is railway commands 🚆. In railway control, there are no confidentiality requirements for commands going between an interlocking controller and a railway equipment controller. Think of a point controller on a tram track, where the point's position is already public 👀. Integrity and authenticity of those commands are, however, vital. Otherwise an adversary could change the target position of the point by modifying commands, and that could derail a passing train 😨. There's also flight-data recording of safety-related network traffic. That kind of recording can only meet its requirements with authenticity-only ciphers, because a third party usually analyzes it after an accident, and that third party needs to pull the safety-related commands out of the recording 🔍.

The fifth use case is civil aviation and ground communication ✈️. Pilots send and receive messages to and from ground control, like route-of-flight updates, weather info, controller and pilot communication, and airline back-office messages 📡. Air Traffic Control (ATC) also uses air-to-ground communication to receive surveillance data, which depends on downlink reports from the airplane's avionics 🛰️. This happens automatically under contracts between the ATC ground system and the airplane's avionics, and reports can go out when specific events happen or when certain time intervals are reached ⏰. In many systems, reading this data doesn't give an attacker anything exploitable. It's mostly info about the airplane's state, controller pilot communication, weather, and so on 🌤️. But if someone could modify it, they could put an aircraft on the wrong trajectory or feed false info to ground control, which could delay flights, damage property, or harm life 😭🚫. So data that's not encrypted but is authenticated protects against tampering, and authenticity is enough for air traffic, weather, and surveillance exchanges between airplanes and ground systems 🫶.

Okay, so the big takeaway is that these use cases need no confidentiality, or confidentiality gets in the way of other requirements 🙅‍♀️. Some of these devices have small runtime memory and reduced processing power, so keeping the number of crypto algorithms down is a priority 🧠. That said, the memory, performance, and processing implications of any algorithm depend heavily on hardware and software architecture, so these cipher suites might give performance benefits, but they won't necessarily give them in every case on every platform 🤷‍♀️. And in some use cases, third parties need to inspect the data, which the lack of confidentiality mechanisms actually supports 🔎✨.

4. Cryptographic Negotiation Using Integrity-Only Cipher Suites 🤝

the cryptographic negotiation from [RFC8446], Section 4.1.1 stays the same! 💖 The only change is that we add these two cipher suites to the mix:

TLS_SHA256_SHA256 {0xC0,0xB4}
TLS_SHA384_SHA384 {0xC0,0xB5}

Quick refresher: in TLS 1.3, a cipher suite names the AEAD algorithm for record protection and the hash algorithm used with the HMAC-based Key Derivation Function (HKDF) [RFC8446] 🧩. These new suites are set up the same way, except they use the HMAC authentication tag to model the AEAD interface, since only an HMAC is provided for record protection (no encryption) 🔐. They let you use SHA-256 or SHA-384 as the HMAC for integrity protection, and also for the HKDF 🌸. The authentication mechanisms stay unchanged. The whole point is just to update the cipher suites so confidentiality isn't needed 🍓.

Because these cipher suites don't support confidentiality, they MUST NOT be used with authentication and key exchange methods that rely on confidentiality. That's a hard rule, bestie, no exceptions 🚫💅.

5. Record Payload Protection for Integrity-Only Cipher Suites 🎀

Record payload protection from [RFC8446] is kept, just in a modified form when integrity-only cipher suites are used 🧁. Heads up: because these suites use hash algorithms on purpose instead of AEAD algorithms, the record payload doesn't get confidentiality protection 🫣. This section explains how record payload structures map when these suites are in play 🗺️.

Since there's no encryption happening at the record layer, the operations "Protect" and "Unprotect" take the place of "AEAD-Encrypt" and "AEAD-Decrypt" [RFC8446], respectively 🔄.

Integrity protection covers the full record, so the encrypted_record in the TLSCiphertext, along with the additional_data input to protected_data (called AEADEncrypted data in [RFC8446]), as defined in Section 5.2 of [RFC8446], all stay the same ✨. The TLSCiphertext.length for the integrity cipher suites works out like this:

TLS_SHA256_SHA256:
   TLSCiphertext.length = TLSInnerPlaintext_length + 32

TLS_SHA384_SHA384:
   TLSCiphertext.length = TLSInnerPlaintext_length + 48

Quick note: TLSInnerPlaintext_length isn't an explicit field in [RFC8446]. It just refers to the length of the encoded TLSInnerPlaintext structure 📏.

The resulting protected_record is the TLSInnerPlaintext concatenated with the resulting HMAC 🧵. This is basically the same idea as the "encrypted_record" in [RFC8446], but it's called a "protected_record" because there's no confidentiality via encryption 🔖. With this mapping, the record validation order from Section 5.2 of [RFC8446] stays the same. So the encrypted_record field of TLSCiphertext gets set to:

    encrypted_record = TLS13-HMAC-Protected = TLSInnerPlaintext ||
    HMAC(write_key, nonce || additional_data || TLSInnerPlaintext)

Here, "nonce" refers to the per-record nonce from Section 5.3 of [RFC8446] 🎲.

For DTLS 1.3, the DTLSCiphertext gets set to:

    encrypted_record = DTLS13-HMAC-Protected = DTLSInnerPlaintext ||
    HMAC(write_key, nonce || additional_data || DTLSInnerPlaintext)

For DTLS, "nonce" refers to the per-record nonce from Section 4.2.2 of [DTLS13] 🦋.

The Protect and Unprotect operations provide integrity protection using HMAC SHA-256 or HMAC SHA-384, as described in [RFC6234] 🔐💜.

Last thing, and it's kind of a plot twist 😭: because the plaintext isn't encrypted, record padding doesn't hide the plaintext size at all. You can still include it, though 🙈🌈.

---

6. Key Schedule when Using Integrity-Only Cipher Suites ✨

okay so the key derivation for integrity-only cipher suites is literally the SAME as what [RFC8446] already defines 💅 nothing new to learn. the only plot twist is that the keys protecting the tunnel are for the negotiated HMAC SHA-256 or HMAC SHA-384 ciphers 🔐

the traffic key material (client_write_key, client_write_iv, server_write_key, and server_write_iv) MUST be calculated as per [RFC8446], Section 7.3. bestie, don't freestyle this part 😭

the key lengths and Initialization Vectors (IVs) are based on the hash output lengths, so the sizes are literally just the hash size 🌈 the following key lengths and IV lengths SHALL be:

+===================+============+===========+
| Cipher Suite      | Key Length | IV Length |
+===================+============+===========+
| TLS_SHA256_SHA256 | 32 Bytes   | 32 Bytes  |
+-------------------+------------+-----------+
| TLS_SHA384_SHA384 | 48 Bytes   | 48 Bytes  |
+-------------------+------------+-----------+

                   Table 1

7. Error Alerts 💀

the error alerts from [RFC8446] stay the same, no drama 🫶 the two that matter most here are:

• bad_record_mac: this one can also show up for a record whose message authentication code can't be validated. since these cipher suites don't do record encryption, this alert only happens when the HMAC fails to verify 🙈
• decrypt_error: as described in [RFC8446], Section 6.2, this one happens when the signature or message authentication code can't be validated. the tea is that it's only sent during the handshake, NOT for an error in validating record HMACs 🍓

okay i'm literally obsessed with how precise these are 😭

8. IANA Considerations 🦋

IANA has registered the following cipher suites, defined by this document, in the "TLS Cipher Suites" registry 👑

+===========+===================+=========+=============+
| Value     | Description       | DTLS-OK | Recommended |
+===========+===================+=========+=============+
| 0xC0,0xB4 | TLS_SHA256_SHA256 | Y       | N           |
+-----------+-------------------+---------+-------------+
| 0xC0,0xB5 | TLS_SHA384_SHA384 | Y       | N           |
+-----------+-------------------+---------+-------------+

                         Table 2

9. Security and Privacy Considerations 🚨🚨

okay bestie, this is the serious section and i need you to actually read it 🥺💜

in general, except for confidentiality and privacy, the security considerations in [RFC8446] and [RFC5246] apply to this document. the big catch is that these cipher suites give you NO confidentiality, so they should only be used where there are no confidentiality or privacy requirements or concerns 🛑 (the runtime memory requirements can handle authenticity-only cryptographic constructs, so that part's fine ✨)

with no data encryption, you get no confidentiality or privacy for anything sent through the TLS session. the record layer is NOT encrypted with these cipher suites, and neither is the handshake 😱 the handshake info, including the server and client certificates, is integrity protected but sent in the clear, so anyone can read it. other TLS extensions carried in the server's EncryptedExtensions message are only integrity protected, with no confidentiality at all 🙈

also, any private Pre-Shared Key (PSK) data MUST NOT be sent in the handshake while using these cipher suites 🔑 BUT, because PSKs can be loaded externally, these cipher suites CAN be used with the 0-RTT handshake defined in [RFC8446], with the same security implications discussed there 🧚

application protocols built on TLS or DTLS (like HTTP) might quietly assume their data is confidential 👀 any assumption of data confidentiality is invalidated by these cipher suites, because no data confidentiality is provided. this includes anything sent over the application-data channel (e.g., bearer tokens in HTTP), since data requiring confidentiality MUST NOT be sent using these cipher suites. bearer tokens, we are NOT doing that 💀

limits on key usage for AEAD-based ciphers are described in [RFC8446]. but these cipher suites aren't AEAD, so those same limits don't apply 🤷‍♀️ the general security properties of HMACs discussed in [RFC2104] and [BCK1] still apply. on top of that, the security considerations about the algorithm's strength based on the HMAC key length and truncation length, further described in [RFC4868], also apply 🔥 until further cryptanalysis shows limits on key usage for HMACs, general practice is that implementations put limits on the lifetime of HMAC keys and invoke a key update as described in [RFC8446] before hitting that limit 🌸

DTLS 1.3 defines a way to encrypt DTLS record sequence numbers. but since these cipher suites don't use encryption, the record sequence numbers are sent unencrypted 🙃 the procedure for DTLS record sequence number protection is to apply no protection for these cipher suites.

given the lack of confidentiality, these cipher suites MUST NOT be enabled by default 🛑 they're meant to serve the IoT market, so any IoT endpoint that uses them MUST be explicitly configured with a policy of non-confidential communications. it has to be a deliberate choice, not a default vibe 💜

10. References 📚

10.1. Normative References

[BCK1]     Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash
           Functions for Message Authentication",
           DOI 10.1007/3-540-68697-5_1, 1996,
           <https://link.springer.com/
           chapter/10.1007/3-540-68697-5_1>.

[DTLS13]   Rescorla, E., Tschofenig, H., and N. Modadugu, "The
           Datagram Transport Layer Security (DTLS) Protocol Version
           1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
           <https://www.rfc-editor.org/info/rfc9147>.

[RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
           Hashing for Message Authentication", RFC 2104,
           DOI 10.17487/RFC2104, February 1997,
           <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
           384, and HMAC-SHA-512 with IPsec", RFC 4868,
           DOI 10.17487/RFC4868, May 2007,
           <https://www.rfc-editor.org/info/rfc4868>.

[RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and SHA-based HMAC and HKDF)", RFC 6234,
           DOI 10.17487/RFC6234, May 2011,
           <https://www.rfc-editor.org/info/rfc6234>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

10.2. Informative References

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246,
           DOI 10.17487/RFC5246, August 2008,
           <https://www.rfc-editor.org/info/rfc5246>.

Acknowledgements 🫶

the authors want to give a shoutout to the work done by Industrial Communications Standards Groups (such as ODVA), which motivated this whole document 🏭✨ thanks also to Steffen Fries for a fourth use case and Madhu Niraula for a fifth 🌈 and big love to Joe Salowey, Blake Anderson, David McGrew, Clement Zeller, and Peter Wu for the advice and feedback 💖

Authors' Addresses 🎀

Nancy Cam-Winget
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
United States of America
Email: ncamwing@cisco.com


Jack Visoky
ODVA
1 Allen Bradley Dr
Mayfield Heights, OH 44124
United States of America
Email: jmvisoky@ra.rockwell.com