RFC 9266

Channel Bindings for TLS 1.3

📅 published July 2022, from ietf

RFC 9266: Channel Bindings for TLS 1.3 🎀

Okay bestie, so this one is Channel Bindings for TLS 1.3, written by Sam Whited 💖. It's a Standards Track doc from July 2022, which means it's an official IETF spec and not just vibes 💅. It's ISSN 2070-1721 (very official 🌸). It updates RFCs 5801, 5802, 5929, and 7677 🦋. The header doesn't list anything it obsoletes.

Abstract ✨

Okay so this doc defines a brand new channel binding type called tls-exporter 🦋. It's totally compatible with TLS 1.3, and it follows the rules from RFC 5056, "On the Use of Channel Bindings to Secure Channels." It also swaps the default channel binding over to this new one for any TLS version newer than 1.2, which is giving main character energy 👑. It updates RFCs 5801, 5802, 5929, and 7677 too.

Status of This Memo 📜

This is an Internet Standards Track document 🎀.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨. If you want more info on Internet Standards, check out Section 2 of RFC 7841 🌈.

Info about the current status of this doc, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9266 💜.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 🫶.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info, as they were in effect when this was published. Please read these carefully, because they explain your rights and restrictions for this doc 📖. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🍓.

Table of Contents 🗂️

1.  Introduction
  1.1.  Conventions and Terminology
2.  The 'tls-exporter' Channel Binding Type
3.  TLS 1.3 with SCRAM or GSS-API over SASL
4.  Security Considerations
  4.1.  Uniqueness of Channel Bindings
  4.2.  Use with Legacy TLS
5.  IANA Considerations
  5.1.  Registration of Channel Binding Type
  5.2.  Registration of Channel Binding TLS Exporter Label
6.  References
  6.1.  Normative References
  6.2.  Informative References
Author's Address

1. Introduction 🌸

Okay so the tls-unique channel binding type from [RFC5929] turned out to be vulnerable to the "triple handshake vulnerability" [TRIPLE-HANDSHAKE] unless you also used the extended master secret extension from [RFC7627] 😭. TLS 1.3 uses a complete transcript hash that works similarly to those extended master secret procedures, but nobody analyzed whether channel bindings were safe with TLS 1.3 while the core protocol was being built. So the spec for channel bindings with TLS 1.3 got pushed off 🙈. Appendix C.5 of [RFC8446] points out that TLS 1.3 has no channel bindings yet, and this doc is here to define them and fill that gap 🔥. This doc also updates [RFC5929] by adding a second unique channel binding type, tls-exporter, which takes the place of some uses of tls-unique 🦋.

1.1. Conventions and Terminology 📚

Throughout this doc, the acronym "EKM" refers to "Exported Keying Material," as defined in [RFC5705] 💅.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like this 🎀.

2. The tls-exporter Channel Binding Type 💖

Channel binding mechanisms are useless until TLS implementations actually expose the data they need 😩. To make that happen, tls-exporter uses Exported Keying Material (EKM), which lots of TLS implementations already expose ✨. You get the EKM with the keying material exporters for TLS, as defined in [RFC5705] and Section 7.5 of [RFC8446], and you give it these inputs:

  • Label: The ASCII string EXPORTER-Channel-Binding, with no terminating NUL.
  • Context value: Zero-length string.
  • Length: 32 bytes.

This channel binding mechanism only exists when the TLS handshake gives you unique master secrets. That's true for TLS versions before 1.3 when the extended master secret extension of [RFC7627] is in use, and it's always true for TLS 1.3 (see Appendix D of [RFC8446]) 🦋.

3. TLS 1.3 with SCRAM or GSS-API over SASL 🌈

The specs for Salted Challenge Response Authentication Mechanism (SCRAM) [RFC5802] [RFC7677] and Generic Security Service Application Program Interface (GSS-API) over Simple Authentication and Security Layer (SASL) [RFC5801] both say tls-unique is the default channel binding over TLS 🍓. But tls-unique isn't defined for TLS 1.3 (or anything newer), so this doc updates [RFC5801], [RFC5802], and [RFC7677] to make tls-exporter the default over TLS 1.3 and up 👑. Quick note: this doc does not change the default for SCRAM over TLS 1.2 [RFC5246], which stays tls-unique (and yes, RFC 5246 has been obsoleted by RFC 8446, so keep that in mind 💀).

On top of that, this doc updates those same documents so that tls-exporter becomes the mandatory-to-implement channel binding whenever any channel binding gets implemented for TLS 1.3 💅. Implementations that support channel binding over TLS 1.3 MUST implement tls-exporter. No skipping this one, periodt 🫶.

4. Security Considerations 🔐

Okay this part is serious, so listen up 😭. The channel binding type in this doc is built so that disclosing the channel binding data doesn't leak any secret info about the TLS channel, and it doesn't affect the security of the TLS channel either 🛡️.

The derived data MUST NOT be used for anything other than channel bindings as described in [RFC5056]. Like, at all. Implementations MUST NOT use channel binding as a secret key to protect privileged information 🚫. Bestie, this is a hard rule 💀.

The Security Considerations sections of [RFC5056], [RFC5705], and [RFC8446] also apply to this doc 🌸.

4.1. Uniqueness of Channel Bindings 🦋

The definition of channel bindings in [RFC5056] introduces a "unique" channel binding, which is one that's unique to the channel endpoints and unique over time. In other words, it's a value that's unique to one specific instance of the lower-layer security protocol 🧚. When TLS is the lower-layer security protocol, which is the case for the channel binding type in this doc, uniqueness means you're uniquely identifying that specific TLS connection ✨.

There's also a stronger kind of uniqueness, which would mean uniquely identifying not just the lower-layer protocol but also the upper-layer application or authentication protocol that's using the channel binding 👀. This only matters when multiple instances of an authentication protocol, or multiple different authentication protocols, run on top of the same lower-layer protocol. That's pretty rare, honestly. Most consumers set up one instance of the lower-layer secure protocol, run one application or authentication protocol on top, and then shut down both layers 💅. In that setup, the stronger uniqueness is trivially achieved, since the channel binding value is already unique in the sense of [RFC5056] 🌟.

The channel binding type in this doc only gives the weaker kind of uniqueness, per [RFC5056]. It doesn't get the stronger uniqueness per upper-layer protocol instance described above 🙈. That stronger form would protect against cross-protocol attacks when multiple authentication protocols run over the same instance of the lower-layer protocol. It would also protect against replay attacks, where someone tries to replay a message from one instance of an authentication protocol into a different instance of that same protocol, again over the same lower-layer instance 😱. Both of these properties are super desirable for formal analysis of upper-layer protocols, and without them, formal analysis is basically impossible 💀. Some upper-layer protocols might already provide one or both of these properties, but that depends on the specific mechanisms involved. Formal analysis needs the property to be provided in a generic way across all upper-layer protocols that exist now or might exist later 🫶.

So, applications that use the channel binding type in this doc MUST NOT use the channel binding for more than one authentication mechanism instance on a given TLS connection. These applications MUST immediately close the TLS connection once the upper-layer protocol is done 🔒. No sneaking in a second auth on the same connection, okay? 🚫

4.2. Use with Legacy TLS 🕰️

You can use this channel binding mechanism with TLS versions below 1.3, but you have to be extra careful that your chosen cipher suites always result in unique master secrets 😬. For more on that, check out [RFC7627] and the Security Considerations section of [RFC5705] (TLS 1.3 always gives you unique master secrets, as discussed in Appendix D of [RFC8446]) ✨.

When TLS renegotiation is enabled on a connection, the tls-exporter channel binding type is not defined for that connection, and implementations MUST NOT support it 🚫. Sorry, renegotiation users, it's not it for you 🥲.

Generally speaking, people who want the benefits of channel binding should upgrade to TLS 1.3 or later 🌈💖

6.1. Normative References 🧾

okay these are the receipts 🧾 the spec leans on these to actually work, so they're not optional reading bestie 💅

6.2. Informative References 📚

these ones are extra reading if you want the backstory 🦋

Author's Address 💌

the person who wrote this bestie 🫶

Sam Whited
Atlanta, GA
United States of America
Email: sam@samwhited.com
URI:   https://blog.samwhited.com/
📦 where this page comes from