RFC 7366

Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 🎀

Okay bestie, this is RFC 7366, written by P. Gutmann from the University of Auckland and published by the IETF (Internet Engineering Task Force) in September 2014. It's a Standards Track document, with ISSN 2070-1721. The header has no Obsoletes or Updates line, so it doesn't replace or update any other RFC. 💖

Abstract

So this doc is about how TLS and DTLS can agree to swap MAC-then-encrypt for encrypt-then-MAC. MAC-then-encrypt has been getting absolutely roasted by security vulnerabilities for years 💀

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7366.

Copyright Notice 🌸

Copyright (c) 2014 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 of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to 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.  Conventions Used in This Document . . . . . . . . . . . .   2
2.  Negotiating Encrypt-then-MAC  . . . . . . . . . . . . . . . .   2
  2.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Applying Encrypt-then-MAC  . . . . . . . . . . . . . . . . . .   3
  3.1.  Rehandshake Issues  . . . . . . . . . . . . . . . . . . .   5
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   7

1. Introduction ✨

TLS [2] and DTLS [4] use a MAC-then-encrypt construction. Back when the original Secure Socket Layer (SSL) protocol was specced in the mid-1990s, that was considered secure, but it's not considered secure anymore [5] [6]. This construction, as used in TLS and later DTLS, has been hit by loads of security vulnerabilities and attacks over many years 😭. This doc lays out how to switch to the safer encrypt-then-MAC construction as part of the TLS/DTLS handshake, replacing the current MAC-then-encrypt construction. (In this doc, "MAC" means "Message Authentication Code".)

1.1. Conventions Used in This Document 💅

Here's the key-word situation: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in [1]. 🙈

2. Negotiating Encrypt-then-MAC 🎀

So the switch gets negotiated through TLS/DTLS extensions, as defined in TLS [2]. When a client connects, it adds the encrypt_then_mac extension to its client_hello if it wants encrypt-then-MAC instead of the default MAC-then-encrypt. If the server can meet that, it answers with an encrypt_then_mac in its server_hello. The extension_type value for this extension SHALL be 22 (0x16), and the extension_data field of this extension SHALL be empty. The client and server MUST NOT use encrypt-then-MAC unless both sides have successfully exchanged encrypt_then_mac extensions. No handshake, no encrypt-then-MAC, periodt 💅

2.1. Rationale 🧠

Why extensions and not new ciphersuites? Because new ciphersuites would cause a Cartesian explosion of suites. You'd potentially have to duplicate every single existing suite with a new one that uses encrypt-then-MAC, and that's a mess 😵‍💫. With this approach you only need one new extension type, plus a minimal-length extension sent by the client and server. Clean.

The doc also looked at putting encrypt-then-MAC into TLS 1.3. But that would mean implementing and deploying all of TLS 1.2 just to support a tiny code change in the order of encryption and MAC'ing. The extension route only needed less than a dozen lines of code changed in one implementation (not counting the handling for the new extension type, which was another 50 or so lines). Tiny glow-up energy ✨

Extensions do mean SSL 3.0 is out of the picture. But SSL 3.0 is nearly two decades old, so anything still running it is probably vulnerable to a bunch of other attacks anyway. Why bend over backwards to accommodate it? 🙃

3. Applying Encrypt-then-MAC 🧚

Once encrypt-then-MAC has been negotiated, TLS/DTLS packet processing switches from the standard:

encrypt( data || MAC || pad )

to the new:

encrypt( data || pad ) || MAC

The MAC covers the entire packet up to the start of the MAC value. In TLS [2] notation, the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is:

MAC(MAC_write_key, seq_num +
    TLSCipherText.type +
    TLSCipherText.version +
    TLSCipherText.length +
    ENC(content + padding + padding_length));

and for TLS 1.1 and greater with an explicit IV is:

MAC(MAC_write_key, seq_num +
    TLSCipherText.type +
    TLSCipherText.version +
    TLSCipherText.length +
    IV +
    ENC(content + padding + padding_length));

(For DTLS, the sequence number gets replaced by the combined epoch and sequence number, per DTLS [4].) The final MAC value then gets appended to the encrypted data and padding. The calculation is identical to the existing one, except the MAC is run over the payload ciphertext (the TLSCipherText PDU) instead of the plaintext (the TLSCompressed PDU). 🔐

The overall TLS packet [2] looks like this:

struct {
       ContentType type;
       ProtocolVersion version;
       uint16 length;
       GenericBlockCipher fragment;
       opaque MAC;
       } TLSCiphertext;

And the equivalent DTLS packet [4] looks like this:

struct {
       ContentType type;
       ProtocolVersion version;
       uint16 epoch;
       uint48 sequence_number;
       uint16 length;
       GenericBlockCipher fragment;
       opaque MAC;
       } TLSCiphertext;

The layout is identical to the existing TLS/DTLS one. The only difference is that the MAC value gets moved outside the encrypted data. Simple, but it matters a lot 🦋

Now, the GenericBlockCipher annotation tells us this only applies to standard block ciphers that have distinct encrypt and MAC operations. It does not apply to GenericStreamCiphers, or to GenericAEADCiphers that already include integrity protection with the cipher. So if a server gets an encrypt-then-MAC request extension from a client and then picks a stream or Authenticated Encryption with Associated Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client. ⚠️

Stream and AEAD suites don't get the encrypt-then-MAC response. Don't send it back, no matter what the client asked for.

Decryption runs this in reverse. The MAC SHALL be evaluated before any further processing, such as decryption, is performed. If the MAC verification fails, processing SHALL terminate immediately. For TLS, a fatal bad_record_mac MUST be generated [2]. For DTLS, the record MUST be discarded, and a fatal bad_record_mac MAY be generated [4]. That immediate response to a bad MAC shuts down any timing channels that may be available through manipulated packet data. Chef's kiss 👑

Some implementations would rather use a truncated MAC than a full-length one. In that case, they MAY negotiate a truncated MAC through the TLS truncated_hmac extension, as defined in TLS-Ext [3]. 🍓

3.1. Rehandshake Issues 🔄

The status of encrypt-then-MAC vs. MAC-then-encrypt can change during one or more rehandshakes. Implementations SHOULD keep the current session state across all rehandshakes for that session. (In other words, if the mechanism for the current session is X, the renegotiated session should also use X.) Even though implementations SHOULD NOT change the state during a rehandshake, if they want more flexibility, these rules apply:

+------------------+---------------------+--------------------------+
| Current Session  |     Renegotiated    |      Action to take      |
|                  |       Session       |                          |
+------------------+---------------------+--------------------------+
| MAC-then-encrypt |   MAC-then-encrypt  |        No change         |
|                  |                     |                          |
| MAC-then-encrypt |   Encrypt-then-MAC  |        Upgrade to        |
|                  |                     |     Encrypt-then-MAC     |
|                  |                     |                          |
| Encrypt-then-MAC |   MAC-then-encrypt  |          Error           |
|                  |                     |                          |
| Encrypt-then-MAC |   Encrypt-then-MAC  |        No change         |
+------------------+---------------------+--------------------------+

Table 1: Encrypt-then-MAC with Renegotiation 📊

As the table says, implementations MUST NOT renegotiate a downgrade from encrypt-then-MAC to MAC-then-encrypt. A client or server that doesn't want the mechanism-change-during-rehandshake ability can (as a client) not request a mechanism change, or (as a server) deny the mechanism change. Easy out 🙌

These rules hold across potentially many rehandshakes. Say a session is in the encrypt-then-MAC state, and a rehandshake picks a GenericAEADCiphers ciphersuite. If a later rehandshake then picks a MAC-then-encrypt ciphersuite, that's an error, because the renegotiation has downgraded from encrypt-then-MAC to MAC-then-encrypt (via the AEAD ciphersuite). Not allowed, bestie 🚫

(As the text above already pointed out, implementations SHOULD avoid this ciphersuite calisthenics by keeping the initially negotiated mechanism across all rehandshakes. 🏋️‍♀️)

If an upgrade from MAC-then-encrypt to encrypt-then-MAC is negotiated, as in the second row of the table above, the change takes effect in the first message that follows the Change Cipher Spec (CCS) message. In other words, all messages up to and including the CCS use MAC-then-encrypt, and the message after that continues with encrypt-then-MAC. The switch happens right on schedule 🌈

4. Security Considerations 🔐

okay bestie, this section is the serious one 💀 but it's also kind of iconic. encrypt-then-MAC is the upgrade that's meant to replace the current MAC-then-encrypt setup 🔥. Per the references [5] [6], it's seen as more secure than what we have now ✨. It should help mitigate or eliminate a bunch of attacks on the old mechanism, but only if you follow the MAC processing instructions in Section 3 🫶. So read Section 3 and don't skip it, periodt 💅.

Now the spicy part 🌶️. An active attacker who can pretend to be a client or server that can't handle extensions might trick some implementations into falling back to older protocol versions that don't support extensions 😭. And once you've fallen back, you're also forced off encrypt-then-MAC 💀. The simplest fix is just to avoid falling back to older, less secure versions 🙌. If fallback is unavoidable, the TLS working group is cooking up mechanisms for this problem, which affects every capability negotiated through TLS extensions 🧚 (see [7]). If this kind of attack worries you, go read the TLS working group documents for proper defence mechanisms 🛡️. Don't just trust my vibes on this one, bestie 🙈.

5. IANA Considerations 🦋

IANA has added extension code point 22 (0x16) for the encrypt_then_mac extension to the TLS "ExtensionType Values" registry 💜, as specified in TLS [2]. So it's officially in the registry now, no cap ✨.

6. Acknowledgements 🫶

The author wants to thank Martin Rex, Dan Shumow, and the members of the TLS mailing list for their feedback on this document 🌸. Y'all helped make this happen, and that's so sweet 🥹.

7. References 📚

7.1. Normative References

• [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
• [3] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
• [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.

7.2. Informative References

• [5] 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, December 2000.
• [6] 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, August 2001.
• [7] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", Work in Progress, July 2014.

Author's Address 🎀

Peter Gutmann
University of Auckland
Department of Computer Science
New Zealand

EMail: pgut001@cs.auckland.ac.nz