RFC 8547

TCP-ENO: Encryption Negotiation Option

📅 published May 2019, from ietf

TCP-ENO: Encryption Negotiation Option 🎀

okay so bestie, let's get into RFC 8547 ✨ it's an Experimental doc (not a Standards Track thing, so it's "published for examination, experimental implementation, and evaluation") 🧪 Authors: A. Bittau (Google), D. Giffin (Stanford University), M. Handley (University College London), D. Mazieres (Stanford University), and E. Smith (Kestrel Institute) 💜 It's from May 2019 and it's got ISSN 2070-1721. It doesn't obsolete or update any other RFCs, so it's a fresh start 🌸

The whole point of this doc is giving unencrypted TCP a glow-up 💅 Plenty of legacy protocols don't have a way to say "hey, wanna encrypt?", and lots of old apps can't be upgraded, so TCP-ENO negotiates encryption at the transport layer, out of band, and stays fully backward-compatible 🫶

Abstract

Okay so the vibe is: a ton of TCP traffic is still plain text 😭 Two big reasons. Some legacy protocols have no signaling mechanism (think a STARTTLS-style command) to say "let's encrypt," so incremental rollout is basically impossible 🙈 And legacy apps often can't be upgraded at all, so they need encryption to happen transparently inside the transport layer 🧚 TCP-ENO fixes both by adding a new TCP option kind that negotiates encryption out of band and is fully backward-compatible 💖

Status of This Memo

This doc is not a Standards Track spec 🙅‍♀️ It's just here for people to examine, experiment with, and evaluate 🔬

It defines an Experimental Protocol for the Internet community ✨ It's an IETF product, it reflects IETF community consensus, got public review, and was approved by the IESG 🦋 Not every IESG-approved doc is a candidate for an Internet Standard, so check Section 2 of RFC 7841 for the deets 💅

Want the current status, errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc8547 🌈

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as of the publication date. Read those carefully, since they spell out your rights and restrictions for this doc 📜 Any Code Components pulled out of this doc have to include Simplified BSD License text (see Section 4.e of the Trust Legal Provisions) and come without warranty, as the Simplified BSD License describes 🍓

Table of Contents

Here's the full map of the doc 🗺️ (page numbers are from the original, so they're just for reference):

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Design Goals . . . . . . . . . . . . . . . . . . . . . .   4
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  TCP-ENO Specification . . . . . . . . . . . . . . . . . . . .   6
  4.1.  ENO Option  . . . . . . . . . . . . . . . . . . . . . . .   7
  4.2.  The Global Suboption  . . . . . . . . . . . . . . . . . .   9
  4.3.  TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . .  10
  4.4.  Specifying Suboption Data Length  . . . . . . . . . . . .  11
  4.5.  The Negotiated TEP  . . . . . . . . . . . . . . . . . . .  12
  4.6.  TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . .  13
  4.7.  Data in SYN Segments  . . . . . . . . . . . . . . . . . .  14
  4.8.  Negotiation Transcript  . . . . . . . . . . . . . . . . .  16
5.  Requirements for TEPs . . . . . . . . . . . . . . . . . . . .  16
  5.1.  Session IDs . . . . . . . . . . . . . . . . . . . . . . .  18
6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
7.  Future Developments . . . . . . . . . . . . . . . . . . . . .  21
8.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .  22
  8.1.  Handshake Robustness  . . . . . . . . . . . . . . . . . .  22
  8.2.  Suboption Data  . . . . . . . . . . . . . . . . . . . . .  22
  8.3.  Passive Role Bit  . . . . . . . . . . . . . . . . . . . .  22
  8.4.  Application-Aware Bit . . . . . . . . . . . . . . . . . .  23
  8.5.  Use of ENO Option Kind by TEPs  . . . . . . . . . . . . .  24
  8.6.  Unpredictability of Session IDs . . . . . . . . . . . . .  24
9.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . .  24
10. Security Considerations . . . . . . . . . . . . . . . . . . .  25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
  12.1.  Normative References . . . . . . . . . . . . . . . . . .  28
  12.2.  Informative References . . . . . . . . . . . . . . . . .  29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  30
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  30
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1. Introduction 🌸

Tons of apps and protocols on top of TCP still don't encrypt their traffic 😤 That lowers the bar for attacks and hurts both user privacy and system security 🙅‍♀️ So we need a minimally intrusive, backward-compatible way to roll out encryption bit by bit, and TCP-ENO is that mechanism ✨

Adding TCP options, extending OS interfaces for TCP-level encryption, and updating apps to use it all take real effort 💅 So ideally, the work you put into TCP-level encryption today should still be useful if the encryption strategy changes later 🦋 That's why it helps to think about two questions separately:

  1. How to negotiate the use of encryption at the TCP layer
  2. How to perform encryption at the TCP layer

This doc tackles question 1 with a new TCP option, ENO 🎀 TCP-ENO gives two endpoints a framework to agree on one TCP encryption protocol (TEP) out of several options 🧚 TEPs can differ a lot in wire format, how they use TCP option space, and how they fit with the TCP header and segmentation 🌈 ENO hides those differences, so new TEPs can slide in without apps noticing 💖

Question 2 is handled by one or more companion TEP docs 📚 Current TEPs already encrypt TCP traffic, and TCP-ENO makes sure today's effort also pays off for future ones 👑

1.1. Design Goals 🍓

TCP-ENO was built around these goals:

  1. Let endpoints negotiate a separately specified TEP that's good for either opportunistic security [RFC7435] of arbitrary TCP traffic or stronger security for apps that do endpoint authentication 🔐
  2. Fall back to plain unencrypted TCP, transparently, when both endpoints don't support it ⬇️
  3. Provide out-of-band signaling so apps can make better use of TCP-level encryption (like improving authentication when TCP-level encryption is in play) 💜
  4. Define a standard negotiation transcript that TEPs can use to defend against tampering with TCP-ENO 🛡️
  5. Make parsimonious use of TCP option space 🤏
  6. Define roles for the two ends of a TCP connection, so each end can be named for encryption or authentication purposes, even after a symmetric simultaneous open 🫶

2. Requirements Language ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174] only when they show up in ALL CAPS, just like here 💅

3. Terminology 📖

A few terms come up all over this doc 🎀 Several of them have more detailed normative definitions in [RFC793] 🧐

SYN segment A TCP segment with the SYN flag set 🚦

ACK segment A TCP segment with the ACK flag set (so that covers most segments apart from an initial SYN segment) 💫

Non-SYN segment A TCP segment with the SYN flag clear 🙃

SYN-only segment A TCP segment with the SYN flag set and the ACK flag clear 🎯

SYN-ACK segment A TCP segment with both the SYN and ACK flags set 🤝

Active opener A host that starts a connection by sending a SYN-only segment 🚀 With the BSD socket API, an active opener calls "connect" ✨ In client-server setups, active openers are usually the clients 🧃

Passive opener A host that doesn't send a SYN-only segment, but answers one with a SYN-ACK segment 🌙 With the BSD socket API, passive openers call "listen" and "accept" instead of "connect" 🎧 In client-server setups, passive openers are usually the servers 🖥️

Simultaneous open Two active openers symmetrically set up a TCP connection with each other (both call "connect" with BSD sockets) 👯‍♀️ Each host in a simultaneous open sends both a SYN-only and a SYN-ACK segment 🤯 It's less common than an asymmetric open with one active and one passive opener, but peer-to-peer apps can use it for NAT traversal [RFC5382] 🕳️

TEP A TCP encryption protocol meant for TCP-ENO and specified in a separate doc 🔒

TEP identifier A unique 7-bit value in the range 0x20-0x7f that IANA has assigned to a TEP 🔢

Negotiated TEP The one TEP that governs a TCP connection, picked by the TCP ENO option defined in this doc 🏆

4. TCP-ENO Specification 🎀

TCP-ENO extends TCP connection setup so encryption can happen opportunistically 🦋 It uses a new TCP option kind [RFC793] to negotiate one TEP out of several possible ones 🧚 The negotiation has hosts swap sets of supported TEPs, where each TEP is a suboption inside a bigger TCP ENO option in the offering host's SYN segment 💌

If TCP-ENO works, it hands you the following info:

  • a negotiated TEP, represented by a unique 7-bit TEP identifier 🏷️
  • a few extra bytes of suboption data from each host, if the TEP needs them 🧩
  • a negotiation transcript for fighting attacks on the negotiation itself 🕵️‍♀️
  • role assignments that name one endpoint "host A" and the other "host B" 👑
  • a bit that higher-layer protocols at each endpoint can use for out-of-band negotiation of updated behavior when TCP encryption is in play 🫧

If TCP-ENO fails, encryption gets turned off and the connection falls back to regular unencrypted TCP 🥲

The rest of this section is the normative description of the TCP ENO option and handshake protocol 📜

Part 1 of 7 is done, bestie 💖 Next up: the TCP ENO option itself (Section 4.1, the ENO Option) 🎀 Keep your eyes peeled 👀✨

4.1. ENO Option ✨

okay so TCP-ENO hides inside the TCP header as an option 🦋 (the TCP header itself is from [RFC793]). Figure 1 shows the basic shape:

         byte    0     1     2             N+1   (N+2 bytes total)
              +-----+-----+-----+--....--+-----+
              |Kind=|Len= |                    |
              |  69 | N+2 | contents (N bytes) |
              +-----+-----+-----+--....--+-----+

                       Figure 1: The TCP-ENO Option

The contents of an ENO option come in two flavors 💅. A SYN-form one (Figure 2) only shows up in SYN segments, and a non-SYN-form one (Figure 3) only shows up in non-SYN segments. The SYN-form option is basically a container holding zero or more suboptions, labeled "Opt_0", "Opt_1", ... in Figure 2. The non-SYN-form option is giving one-bit acknowledgment energy 🫶: its mere presence is the whole signal, and ENO ignores whatever contents it carries. Particular TEPs MAY assign additional meaning to the contents of non-SYN-form ENO options. When a negotiated TEP does not assign such meaning, the contents of a non-SYN-form ENO option MUST be zero bytes (i.e., N = 0) in sent segments and MUST be ignored in received segments.

         byte    0     1     2     3                     ... N+1
              +-----+-----+-----+-----+--...--+-----+----...----+
              |Kind=|Len= |Opt_0|Opt_1|       |Opt_i|   Opt_i   |
              |  69 | N+2 |     |     |       |     |   data    |
              +-----+-----+-----+-----+--...--+-----+----...----+

                       Figure 2: SYN-Form ENO Option
                      byte   0     1     2     N+1
                          +-----+-----+-----...----+
                          |Kind=|Len= |  ignored   |
                          |  69 | N+2 | by TCP-ENO |
                          +-----+-----+-----...----+

            Figure 3: Non-SYN-Form ENO option, Where N MAY Be 0

Every suboption starts with a byte shaped like Figure 4 🌸. The high bit "v", when set, introduces suboptions with variable-length data. When v = 0, the byte itself is the entire suboption. The remaining 7-bit value, called "glt", has three possible jobs:

  • Global configuration data (discussed in Section 4.2)
  • Suboption data length for the next suboption (discussed in Section 4.4)
  • An offer to use a particular TEP defined in a separate TEP specification document
      bit   7   6   5   4   3   2   1   0
          +---+---+---+---+---+---+---+---+
          | v |            glt            |
          +---+---+---+---+---+---+---+---+

          v   - non-zero for use with variable-length suboption data
          glt - Global suboption, Length, or TEP identifier

                Figure 4: Format of Initial Suboption Byte

Table 1 is your cheat sheet for initial suboption bytes 🍓. glt values below 0x20 are for global suboptions and length info (the "gl" in "glt"), while 0x20 and up are TEP identifiers (the "t"). With v = 0, the byte is the whole suboption, so all the info lives in that 7-bit glt, which can be a global suboption or a TEP identifier. With v = 1, it means a suboption with variable-length data. Only TEP identifiers carry suboption data, never global suboptions. So bytes with v = 1 and glt < 0x20 are not global suboptions at all. They're length bytes governing the length of the next suboption (which MUST be a TEP identifier). And if there's no length byte, a TEP identifier suboption with v = 1 has suboption data stretching all the way to the end of the TCP option 😭

       +-----------+---+-------------------------------------------+
       | glt       | v | Meaning                                   |
       +-----------+---+-------------------------------------------+
       | 0x00-0x1f | 0 | Global suboption (Section 4.2)            |
       | 0x00-0x1f | 1 | Length byte (Section 4.4)                 |
       | 0x20-0x7f | 0 | TEP identifier without suboption data     |
       | 0x20-0x7f | 1 | TEP identifier followed by suboption data |
       +-----------+---+-------------------------------------------+

                  Table 1: Initial Suboption Byte Values

A SYN segment MUST contain at most one TCP ENO option. If a SYN segment contains more than one ENO option, the receiver MUST behave as though the segment contained no ENO options and disable encryption. A TEP MAY specify the use of multiple ENO options in a non-SYN segment. For non-SYN segments, ENO itself only distinguishes between the presence or absence of ENO options, so multiple ENO options are interpreted the same as one ✨

4.2. The Global Suboption 🎀

Suboptions 0x00-0x1f are the global config crew, and they apply no matter which TEP ends up negotiated 👑 A TCP SYN segment MUST include at most one ENO suboption in this range. A receiver MUST ignore all but the first suboption in this range in any given TCP segment. Why? So that future updates to ENO can give new meaning to bits in later global suboptions 🧚 The value of a global suboption byte is read as a bit mask, shown in Figure 5.

               bit   7   6   5   4   3   2   1   0
                   +---+---+---+---+---+---+---+---+
                   | 0 | 0 | 0 |z1 |z2 |z3 | a | b |
                   +---+---+---+---+---+---+---+---+

                   b  - Passive role bit
                   a  - Application-aware bit
                   z* - Zero bits (reserved for future use)

               Figure 5: Format of the Global Suboption Byte

Okay, here's how the bit mask fields work 🔥

b (the passive role bit): The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations MUST provide an API through which an application can explicitly set b = 1 before initiating an active open. (Manual configuration of "b" is only necessary to enable encryption with a simultaneous open and requires prior coordination to ensure exactly one endpoint sets b = 1 before connecting.) See Section 8.3 for further discussion 💜

a (the application-aware bit): Legacy applications can benefit from ENO-specific updates that improve endpoint authentication or avoid double encryption. The application-aware bit "a" is an out-of-band signal that higher-layer protocols can use to switch on ENO-specific updates that wouldn't otherwise be backwards compatible 🌈 Implementations MUST set this bit to zero by default, and MUST provide an API through which applications can change the value of the bit as well as examine the value of the bit sent by the remote host. Implementations MUST furthermore support a mandatory application-aware mode, where TCP-ENO is automatically disabled if the remote host does not set a = 1. See Section 8.4 for further discussion 🙈

z1, z2, z3 (the zero bits): The "z" bits are reserved for future updates to TCP-ENO. They MUST be set to zero in sent segments and MUST be ignored in received segments 🍓

A SYN segment without an explicit global suboption has an implicit global suboption of 0x00. Because passive openers MUST always set b = 1, they can't rely on that implicit 0x00 byte, so they MUST include an explicit global suboption in their SYN-ACK segments 💅

4.3. TCP-ENO Roles 🦋

TCP-ENO uses abstract roles called "A" and "B" to tell the two ends of a TCP connection apart. These roles are determined by the "b" bit in the global suboption. The host that sent an implicit or explicit suboption with b = 0 plays the A role, and the host that sent b = 1 plays the B role. Because a passive opener MUST set b = 1 and an active opener by default has b = 0, the normal case is that the active opener plays role A and the passive opener plays role B 🌸

Applications doing a simultaneous open, if they want TCP-level encryption, need to arrange for exactly one endpoint to set b = 1 (even though it's an active opener) while the other endpoint keeps the default b = 0. Otherwise, if both sides use the default b = 0, or if both sides set b = 1, then TCP-ENO will fail and fall back to unencrypted TCP 💀 Likewise, if an active opener explicitly configures b = 1 and connects to a passive opener (which MUST always have b = 1), then TCP-ENO will fail and fall back to unencrypted TCP. Oof, no encryption for you 😭

TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify asymmetric behavior by the two hosts. For the rest of this document, we'll use the terms "host A" and "host B" to designate the hosts with roles A and B, respectively, in a connection 👑

4.4. Specifying Suboption Data Length ✨

okay so a TEP can optionally carry one or more bytes of suboption data 🎀 If it does, it sets v = 1 in the first suboption byte (see Figure 4). Any suboption whose TEP identifier has v = 1 (so its first octet is 0xa0 or higher) runs all the way to the end of the TCP option 💅 That means if only one suboption needs data, the most compact move is to put it last in the ENO option, after everything else. In Figure 2, the last suboption, Opt_i, has data and therefore needs v = 1. The suboption data length is inferred from the total length of the TCP option, so it's giving efficiency 🧚

When a suboption with data is not last, the sender MUST explicitly specify the suboption data length so the receiver knows where the next suboption begins 🫶 The sender does this by putting a length byte in front of the suboption, shown in Figure 6. That length byte encodes a 5-bit value, nnnnn. Add one to nnnnn and you get the length of the suboption data (not counting the length byte or the TEP identifier). So a length byte can describe anywhere from 1 to 32 bytes of suboption data, inclusive 🌸

               bit   7   6   5   4   3   2   1   0
                   +---+---+---+-------------------+
                   | 1   0   0         nnnnn       |
                   +---+---+---+-------------------+

                   nnnnn - 5-bit value encoding (length - 1)

                     Figure 6: Format of a Length Byte

A suboption that comes after a length byte MUST be a TEP identifier (glt >= 0x20) and MUST have v = 1. Figure 7 is an example of one 🦋

       byte    0      1       2      nnnnn+2  (nnnnn+3 bytes total)
            +------+------+-------...-------+
            |length| TEP  | suboption data  |
            | byte |ident.| (nnnnn+1 bytes) |
            +------+------+-------...-------+

            length byte    - specifies nnnnn
            TEP identifier - MUST have v = 1 and glt >= 0x20
            suboption data - length specified by nnnnn+1

                   Figure 7: Suboption with Length Byte

A host MUST ignore an ENO option in a SYN segment and MUST disable encryption if either of these happens 😭

  1. A length byte says the suboption data would run past the end of the TCP ENO option.
  2. A length byte is followed by an octet in the range 0x00-0x9f (meaning the following byte has v = 0 or glt < 0x20).

Because the last suboption in an ENO option is special-cased to get its length from the 8-bit TCP option length, it MAY contain more than 32 bytes of suboption data. Every other suboption is capped at 32 bytes by the length byte format 💀 The TCP header can only fit 40 bytes of options in total. So no matter which length byte format is used, a segment can't hold more than one suboption over 32 bytes. That said, TEPs MAY define multiple suboptions with the same TEP identifier in the same SYN segment, which is another way to send over 32 bytes of suboption data even with length bytes 🌈

4.5. The Negotiated TEP 👑

okay this section is about which TEP actually wins 🏆 A TEP identifier glt (with glt >= 0x20) is valid for a connection when all of these are true:

  1. Each side has sent a suboption for glt in its SYN-form ENO option.
  2. Any suboption data in these glt suboptions is valid according to the TEP specification and meets any runtime constraints.
  3. If an ENO option contains multiple suboptions with glt, that repetition is well-defined by the TEP specification.

A passive opener (which is always host B) sees the remote host's SYN before building its own SYN-ACK 👀 So a passive opener SHOULD include only one TEP identifier in its SYN-ACK segments, and SHOULD make sure that identifier is valid. Still, simultaneous open or implementation details can stop host B from offering just one TEP 🙈

To handle the case where host B sends several TEP identifiers in the SYN-ACK, the negotiated TEP is defined as the last valid TEP identifier in host B's SYN-form ENO option. Basically, host B lists TEP suboptions in order of increasing priority, while host A has no say in TEP priority 💅

4.6. TCP-ENO Handshake 🤝

this is the handshake drama, bestie 🎭 A host using TCP-ENO for a connection MUST include an ENO option in every TCP segment it sends, until either encryption is disabled or it receives a non-SYN segment. This means an active opener MUST include a non-SYN-form ENO option in the third segment of the three-way handshake 🧚

A host MUST disable encryption, stop sending any more ENO options, and fall back to unencrypted TCP if any of these happens:

  1. Any segment it receives up to and including the first received ACK segment has no ENO option (or has an ill-formed SYN-form ENO option).
  2. The SYN segment it receives has no valid TEP identifier.
  3. It receives a SYN segment with an incompatible global suboption. (Here "incompatible" means the two hosts set the same "b" value, or the connection is in mandatory application-aware mode and the remote host set a = 0.)

Hosts MUST NOT alter SYN-form ENO options in retransmitted segments, or between the SYN and SYN-ACK of a simultaneous open 🙅‍♀️ There are two exceptions, both for an active opener. First, an active opener MAY unilaterally disable ENO (and so remove the ENO option) between retransmissions of a SYN-only segment. (That removal could help recovery from middleboxes that drop segments with ENO options.) Second, an active opener doing a simultaneous open MAY leave out the TCP-ENO option from its SYN-ACK if the SYN it received caused it to disable encryption under the rules above (for instance, because role negotiation failed) 🌸

Once a host has both sent and received an ACK segment containing an ENO option, encryption MUST be enabled. After that, hosts MUST follow the specification of the negotiated TEP and MUST NOT present raw TCP payload data to the application. Specifically, data segments MUST NOT contain plaintext application data. They carry ciphertext, key negotiation parameters, or other messages, as the negotiated TEP decides 🔐

A host MAY send a SYN-form ENO option that contains zero TEP identifier suboptions, which we call a "vacuous" ENO option 🫧 If either host's SYN segment has a vacuous ENO option, that means there are no valid TEP identifiers for the connection, so the connection MUST fall back to unencrypted TCP. Hosts MAY send vacuous ENO options to say ENO is supported but unavailable through configuration, or to probe network paths for robustness to ENO options. However, a passive opener MUST NOT send a vacuous ENO option in a SYN-ACK unless the SYN it received had an ENO option. And a passive opener's SYN-form ENO option MUST still include a global suboption with b = 1, as discussed in Section 4.3 ✨

4.7. Data in SYN Segments 📦

TEPs MAY specify using data in SYN segments, so connection setup can take fewer round trips 🚀 The meaning of data in a SYN segment with an ENO option (a SYN+ENO segment) is set by the last TEP identifier in that ENO option. We call that the segment's "SYN TEP". A SYN+ENO segment MAY of course include multiple TEP suboptions, but only the SYN TEP (the last one) says how to read the segment's data payload 🎀

A host sending a SYN+ENO segment MUST NOT include data in it unless the SYN TEP's specification defines the use of such data. And to avoid conflicting readings of SYN data, a SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) option [RFC7413] 🙅‍♀️

Since a host can send SYN data before it knows which TEP, if any, the connection will negotiate, hosts implementing ENO are REQUIRED to discard data from SYN+ENO segments when the SYN TEP does not become the negotiated TEP. Hosts are also REQUIRED to discard SYN data when another Internet standard specifies a conflicting meaning for it (for example, when a non-empty TFO option shows up). This requirement applies to hosts that implement ENO even when ENO has been turned off by configuration. Note, though, that discarding SYN data is already common practice [RFC4987], and the new requirement only applies to segments that contain ENO options 🌷

More specifically, a host that implements ENO MUST discard the data in a received SYN+ENO segment if any of these applies:

  • ENO fails and TEP-indicated encryption is disabled for the connection.
  • The received segment's SYN TEP is not the negotiated TEP.
  • The negotiated TEP does not define the use of SYN data.
  • The SYN segment contains a non-empty TFO option or any other TCP option that implies a conflicting definition of SYN data.

A host that discards SYN data under the requirement above MUST NOT acknowledge the sequence number of the discarded data. Instead, it MUST acknowledge the other host's initial sequence number as if the received SYN segment had no data 🫶 Also, after discarding SYN data, that host MUST NOT assume the SYN data will be retransmitted identically, and MUST process data only from non-SYN segments 💅

If a host sends a SYN+ENO segment with data and gets an acknowledgment for that data, but the SYN TEP in its transmitted SYN segment is not the negotiated TEP (because either a different TEP was negotiated, or ENO failed to negotiate encryption), then the host MUST abort the TCP connection. Doing anything else risks misinterpreted SYN data 😭

If a host sends a SYN-only SYN+ENO segment carrying data and then gets a SYN-ACK segment without an ENO option, that host MUST abort the connection, even if the SYN-ACK does not acknowledge the SYN data 🚨 The reason is that the receiver could still have cached the unacknowledged data. Later retransmissions meant to replace that data could fail to do so if the receiver gives the cached original data priority. Implementations MAY provide an API call for a non-default mode in which unacknowledged SYN data does not abort the connection. But applications MUST use this mode only when a higher-layer integrity check would terminate a garbled connection anyway 🧐

To avoid surprise connection aborts, ENO implementations MUST disable the use of data in SYN-only segments by default. Such data MAY be enabled through an API command. In particular, implementations MAY provide a per-connection mandatory encryption mode that automatically aborts a connection if ENO fails, and they MAY enable SYN data in that mode 🌈

To meet the requirement in the previous paragraph, all TEPs SHOULD support a normal mode of operation that avoids data in SYN-only segments. The exception is TEPs that are intended to be disabled by default 🦋

4.8. Negotiation Transcript 📜

okay so bestie, to stop sneaky people from messing with the negotiation itself 🕵️‍♀️, a TEP MUST, with high probability, fail to set up a working connection between two ENO-compliant hosts if the SYN-form ENO options got altered in transit. (Obvi, without endpoint authentication, two compliant hosts can still each end up chatting with a man-in-the-middle attacker 😬.) To catch SYN-form ENO option tampering, TEPs MUST reference a transcript of TCP-ENO's negotiation. 🔍

TCP-ENO's transcript is a packed data structure made of two TCP-ENO options, exactly as they showed up in the TCP header, kind and length bytes included (see Figure 1). It's built from these, in this order:

  1. The TCP-ENO option in host A's SYN segment, including the kind and length bytes
  2. The TCP-ENO option in host B's SYN segment, including the kind and length bytes

The iconic part is this: because the ENO options in the transcript carry TCP's length bytes, the transcript clearly separates A's option from B's. 💅

5. Requirements for TEPs 📋

TCP-ENO gives TEP specs a LOT of design freedom 🦋. But to hide TEP differences from applications, everything has to fit into one coherent framework, so any TEP claiming an ENO TEP identifier MUST satisfy the following list of properties. Think of it as the TEP checklist, no skipping! ✨

  • TEPs MUST protect TCP data streams with authenticated encryption. (Note that "authenticated encryption" only refers to the form of encryption, like an Authenticated Encryption with Associated Data (AEAD) algorithm meeting the requirements of [RFC5116]. It does not imply endpoint authentication.)
  • TEPs MUST define a session ID whose value identifies the TCP connection and, with overwhelming probability, is unique over all time if either host correctly obeys the TEP. Section 5.1 breaks down the session ID requirements in more detail. 🆔
  • TEPs MUST NOT make data confidentiality dependent on encryption algorithms with a security strength [NIST-SP-800-57] of less than 120 bits. The number 120 was picked to accommodate ciphers with 128-bit keys that lose a few bits of security, either to particularities of the key schedule or to highly theoretical and unrealistic attacks. 🔐
  • TEPs MUST NOT allow the negotiation of null cipher suites, even for debugging purposes. (Implementations MAY support debugging modes that allow applications to extract their own session keys.)
  • TEPs MUST guarantee the confidentiality of TCP streams without assuming the security of any long-lived secrets. Implementations SHOULD provide forward secrecy soon after the close of a TCP connection, and SHOULD therefore bound the delay between closing a connection and erasing any relevant cryptographic secrets. (Exceptions to forward secrecy are permissible only at the implementation level, and only in response to hardware or architectural constraints, e.g., storage that cannot be securely erased.) 🧊
  • TEPs MUST protect and authenticate the end-of-file marker conveyed by TCP's FIN flag. In particular, a receiver MUST, with overwhelming probability, detect a FIN flag that was set or cleared in transit and doesn't match the sender's intent. A TEP MAY discard a segment with such a corrupted FIN bit, or MAY abort the connection in response to such a segment. However, any such abort MUST raise an error condition distinct from an authentic end-of-file condition. 🚨
  • TEPs MUST prevent corrupted packets from causing urgent data to be delivered when none has been sent. There are several ways to do this. For instance, a TEP MAY cryptographically protect the URG flag and urgent pointer alongside ordinary payload data. Alternatively, a TEP MAY disable urgent data functionality by clearing the URG flag on all received segments and returning errors in response to sender-side urgent-data API calls. Implementations SHOULD avoid negotiating TEPs that disable urgent data by default. The exception is when applications and protocols are known never to send urgent data. 🙈

5.1. Session IDs 🪪

Each TEP MUST define a session ID that's computable by both endpoints and uniquely identifies each encrypted TCP connection. Implementations MUST expose the session ID to applications via an API extension. The API extension MUST return an error when no session ID is available, because ENO has failed to negotiate encryption or because no connection is established yet. Applications that are aware of TCP-ENO SHOULD, when practical, authenticate the TCP endpoints by incorporating the values of the session ID and TCP-ENO role (A or B) into higher-layer authentication mechanisms. 🫶

To avoid replay attacks and to stop authenticated session IDs from being used out of context, session IDs MUST be unique over all time with high probability. This uniqueness property MUST hold even if one end of a connection maliciously manipulates the protocol to try to create duplicate session IDs. In other words, it MUST be infeasible for a host, even by violating the TEP specification, to establish two TCP connections with the same session ID to remote hosts that properly implement the TEP. 🚫

To keep session IDs from getting mixed up across TEPs, all session IDs begin with the negotiated TEP identifier, which is the last valid TEP identifier in host B's SYN segment. That initial byte also has bit "v" set to the same value that accompanied the negotiated TEP identifier in B's SYN segment. Only this single byte is included, not any suboption data. Figure 8 shows the resulting format. It's designed for TEPs to compute unique identifiers, and it's NOT meant for application authors to pick apart session IDs. Applications SHOULD treat session IDs as monolithic opaque values, and SHOULD NOT discard the first byte to shorten identifiers. (The exception is non-security-relevant stuff, like gathering statistics about negotiated TEPs.) 📊

                 byte    0     1     2        N-1    N
                      +-----+------------...------------+
                      | sub-| collision-resistant hash  |
                      | opt | of connection information |
                      +-----+------------...------------+

Figure 8: Format of a Session ID

Even though TEP specs keep plenty of flexibility in how they define the session ID, all session IDs MUST meet the following list of requirements:

  • The session ID MUST be at least 33 bytes (including the one-byte suboption), though TEPs MAY choose longer session IDs. 📏
  • The session ID MUST depend, in a collision-resistant way, on all of the following (meaning it's computationally infeasible to produce collisions of the session ID derivation function unless all of the following quantities are identical):
    • Fresh data contributed by both sides of the connection
    • Any public keys, public Diffie-Hellman parameters, or other public asymmetric cryptographic parameters that are employed by the TEP and have corresponding private data known by only one side of the connection
    • The negotiation transcript specified in Section 4.8
  • Unless and until applications disclose information about the session ID, all but the first byte MUST be computationally indistinguishable from random bytes to a network eavesdropper. 🎲
  • Applications MAY choose to make session IDs public. Therefore, TEPs MUST NOT place any confidential data in the session ID (such as data permitting the derivation of session keys). 🚨

6. Examples 🎀

This subsection illustrates the TCP-ENO handshake with a few non-normative examples. 🧚

         (1) A -> B:  SYN      ENO<X,Y>
         (2) B -> A:  SYN-ACK  ENO<b=1,Y>
         (3) A -> B:  ACK      ENO<>
         [rest of connection encrypted according to TEP Y]

Figure 9: Three-Way Handshake with Successful TCP-ENO Negotiation

Figure 9 shows a three-way handshake with successful TCP-ENO negotiation. Host A includes two ENO suboptions with TEP identifiers X and Y. Host A doesn't include an explicit global suboption, which means it has an implicit global suboption 0x00 conveying passive role bit b = 0. The two sides agree to follow the TEP identified by suboption Y. 🤝

            (1) A -> B:  SYN      ENO<X,Y>
            (2) B -> A:  SYN-ACK
            (3) A -> B:  ACK
            [rest of connection unencrypted legacy TCP]

Figure 10: Three-Way Handshake with Failed TCP-ENO Negotiation

Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) indicates support for TEPs corresponding to suboptions X and Y. Unfortunately, at this point, one of several things happens:

  1. The passive opener (B) doesn't support TCP-ENO.
  2. B supports TCP-ENO but supports neither TEP X nor Y, so it doesn't reply with an ENO option.
  3. B supports TCP-ENO but has the connection configured in mandatory application-aware mode, and thus disables ENO because A's SYN segment contains an implicit global suboption with a = 0.
  4. The network stripped the ENO option out of A's SYN segment, so B never received it.

Whichever of the above applies, the connection transparently falls back to unencrypted TCP. 🥲

   (1) A -> B:  SYN      ENO<X,Y>
   (2) B -> A:  SYN-ACK  ENO<b=1,X> [ENO stripped by middlebox]
   (3) A -> B:  ACK
   [rest of connection unencrypted legacy TCP]

Figure 11: Failed TCP-ENO Negotiation Because of Option Stripping

Figure 11 shows another handshake with a failed encryption negotiation. This time, the passive opener (B) receives an ENO option from A and replies. However, the reverse network path from B to A strips ENO options. Therefore, A doesn't receive an ENO option from B, it disables ENO, and it doesn't include a non-SYN-form ENO option in segment 3 when ACKing B's SYN. Had A not disabled encryption, Section 4.6 would have required it to include a non-SYN-form ENO option in segment 3. The omission of this option tells B that encryption negotiation has failed, after which the two hosts carry on with unencrypted TCP. 🙅‍♀️

             (1) A -> B:  SYN      ENO<Y,X>
             (2) B -> A:  SYN      ENO<b=1,X,Y,Z>
             (3) A -> B:  SYN-ACK  ENO<Y,X>
             (4) B -> A:  SYN-ACK  ENO<b=1,X,Y,Z>
             [rest of connection encrypted according to TEP Y]

Figure 12: Simultaneous Open with Successful TCP-ENO Negotiation

Figure 12 shows a successful TCP-ENO negotiation with simultaneous open. Here, the first four segments contain a SYN-form ENO option, since each side sends both a SYN-only and a SYN-ACK segment. The ENO option in each host's SYN-ACK is identical to the ENO option in its SYN-only segment, because otherwise connection establishment couldn't recover from the loss of a SYN segment. The last valid TEP in host B's ENO option is Y, so Y is the negotiated TEP. 👑✨

7. Future Developments ✨

okay so TCP-ENO is built to glow up alongside whatever comes next 💅 The trade-offs could shift and change the best way to do TCP-level encryption (beyond just adding new cipher suites). Here are a few possible plot twists we can think about 🦋

Lowkey there are a bunch of proposals to make the option space in the TCP header bigger. They're super experimental, especially the ones that touch SYN segments 🙈 So future TEPs probably won't be getting extra SYN option space anytime soon. But if it ever does get extended, future TEPs could put key agreement messages right inside SYN segments, which is so iconic. In that situation, the 32-byte limit on length bytes might not be enough 😭 This document is intentionally going to abort TCP-ENO if a length byte is followed by an octet in the range 0x00-0x9f. If it's needed, a future update to this document could define a format for bigger suboptions by giving meaning to those byte sequences that are currently undefined 🧚

New revisions to socket interfaces [RFC3493] might add library calls that can see both the hostname info and the underlying TCP connection at the same time. That opens the door to authenticating servers transparently to the app, especially with things like DNS-Based Authentication of Named Entities (DANE) [RFC6394] 🔥 An update to TCP-ENO could use one of the "z" bits in the global suboption to negotiate an endpoint authentication protocol before the app touches the TCP connection at all. Over time, the fallout from failed or missing endpoint authentication could ramp up from just logging messages to aborting the connection, if some DNS record (not specified yet) says authentication is mandatory 👑 And through shared library updates, that endpoint authentication could potentially get added to legacy apps without recompiling them. Iconic, honestly 🌈

Right now TLS can only be added to legacy apps whose protocols have a STARTTLS command or something equivalent 💀 TCP-ENO does its signaling out-of-band, so it opens the possibility of future TLS revisions being generically applicable to any TCP application ✨

8. Design Rationale 🎀

this section is the "why" behind TCP-ENO, so get comfy 🫶

8.1. Handshake Robustness 🛡️

Incremental deployment of TCP-ENO depends hard on failure cases quietly falling back to unencrypted TCP, instead of making the whole TCP connection die 💖

Here's the thing: a network path might drop ENO options in only one direction. So a host needs to know not just that the peer supports encryption, but that the peer has actually received an ENO option. That's why ENO keeps encryption disabled unless it gets an ACK segment carrying an ENO option 🙈 To stay robust when segments get dropped, hosts keep including non-SYN-form ENO options in segments until they've received a non-SYN segment from the other side 🍓

One seriously nasty middlebox behavior out in the wild is load balancers that echo unknown TCP options from SYN segments back to the active opener 😭 The passive role bit "b" in the global suboption makes sure encryption is always disabled in that situation, because sending back a verbatim copy of an active opener's SYN-form ENO option always makes role negotiation fail 🚫

8.2. Suboption Data 🧁

TEPs can use suboption data for session caching, cipher suite negotiation, or other purposes ✨ But TCP limits the total option space used by all options to just 40 bytes, so having a bunch of suboptions with data is basically impractical 💀 Because of that, ENO optimizes the case of a single suboption with data by inferring the length of the last suboption from the TCP option length. This saves one byte 🦋

8.3. Passive Role Bit 🎭

TCP-ENO, TEPs, and applications all have asymmetries that need a way to unambiguously identify one of the two connection endpoints 👑 For example, Section 4.8 says host A's ENO option comes before host B's in the negotiation transcript. Another example: an application might need to authenticate one end of a TCP connection with a digital signature. To make sure the signed message can't be interpreted out of context to authenticate the other end, the signed message would need to include both the session ID and the local role, A or B 🔐

A normal TCP three-way handshake has one active opener and one passive opener. That asymmetry is captured by the default configuration of the "b" bit in the global suboption 💅 With simultaneous open, though, both hosts are active openers, so TCP-ENO requires that one host explicitly configure b = 1 🙃 An alternate design might break the symmetry automatically so nobody has to configure anything. But all the designs they looked at either lacked robustness or ate up precious SYN option space even when there was no simultaneous open 😭 (The complicating part is that TCP doesn't know it's in a simultaneous open until after it has sent a SYN segment. And with packet loss, one host might never find out it was part of a simultaneous open 🌀)

8.4. Application-Aware Bit 🧠

Apps built before TCP-ENO can potentially level up to take advantage of TCP-level encryption 🚀 For instance, an app designed to only run on trusted networks could use TCP-ENO to run on untrusted networks. But importantly, it needs to authenticate endpoints and session IDs to do that 🔑 On top of user-visible changes like asking for credentials, this kind of authentication needs application-layer protocol changes. Some protocols can handle those changes, for example by adding a new verb like STARTTLS, while others just can't do it in a backwards-compatible way 😩

The application-aware bit "a" in the global suboption is a way to incrementally roll out TCP-ENO-specific enhancements to application-layer protocols that would otherwise lack the extensibility 🦋 Software with the enhancement always sets a = 1 in its own global suboption, but it only turns on the new behavior when the other end of the connection also sets a = 1 ✨

Another related situation: an app might use TCP-ENO as a replacement for legacy application-layer encryption 💜 In that case, if both endpoints support TCP-ENO, application-layer encryption can be turned off in favor of just authenticating the TCP-ENO session ID 👑 But if one endpoint isn't aware of the new TCP-ENO-specific mode, there's little benefit to doing redundant encryption at the TCP layer. The data's already encrypted once at the application layer, and authentication only means something with respect to that application-layer encryption 🙈 The mandatory application-aware mode lets apps avoid double encryption in this case. It sets a = 1 in the local host's global suboption, but it also disables TCP-ENO entirely if the other side hasn't also set a = 1 🚫

Heads up: the application-aware bit isn't needed by apps that already have solid higher-layer encryption, like the kind provided by TLS [RFC8446] or SSH [RFC4253] 💖 To avoid double encryption in those cases, it's enough to disable TCP-ENO by configuration on any ports that have known secure protocols 🔒

8.5. Use of ENO Option Kind by TEPs 🧩

This document doesn't specify how ENO options get used past the first few segments of a connection 🌸 It also doesn't specify what goes inside ENO options in non-SYN segments, only that they're present. So any use of option kind 69 after the SYN exchange doesn't conflict with this document ✅ And since ENO guarantees at most one negotiated TEP per connection, TEPs won't conflict with each other or with ENO if they use option kind 69 for out-of-band signaling in non-SYN segments 🫶

8.6. Unpredictability of Session IDs 🎲

Section 5.1 says that all but the first (TEP identifier) byte of a session ID MUST be computationally indistinguishable from random bytes to a network eavesdropper 😭 This is easy to make happen under standard assumptions about cryptographic hash functions 🔐 This kind of unpredictability helps security in a whole bunch of cases. For example, it lets apps use a session ID from one connection to authenticate a session ID from another, which ties the two connections together 🔗 It also helps make sure TEPs can't just dodge the 33-byte minimum-length requirement for session IDs by padding shorter ones with zeros 🙅‍♀️

9. Experiments 🧪

this document has experimental status because TCP-ENO's viability depends on middlebox behavior that we can only figure out after the fact 🔬 Specifically, we need to find out how much middleboxes will actually allow TCP-ENO to be used. Once TCP-ENO is deployed, we'll be in a much better spot to gather data on two types of failure 📊

  1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP 😬 This can happen if middleboxes strip unknown TCP options, or if they terminate TCP connections and relay data back and forth.
  2. Middleboxes causing TCP-ENO connections to fail completely 💀 This can happen if middleboxes do deep packet inspection and start dropping segments that unexpectedly contain ciphertext, or if they strip ENO options from non-SYN segments after letting them through in SYN segments.

Type-1 failures are tolerable, since TCP-ENO is designed for incremental deployment anyway 🌈 Type-2 failures are way more problematic. If they're common, we'll need to develop techniques to avoid and recover from them 🚨 The experiment succeeds as long as we can avoid type-2 failures and find enough use cases that avoid type-1 failures (possibly along with a gradual path for cutting type-1 failures down even further) 🏆

Beyond basic viability, deploying TCP-ENO will also help us spot and deal with other potential corner cases or relaxations 🔍 For example, does the slight decrease in effective TCP segment payload cause problems for any applications, which would mean restricting how TEPs interpret socket buffer sizes? And conversely, can we relax the prohibition on default TEPs that disable urgent data? 🤔

One last super important metric, tied to the pace of deployment and the incidence of type-1 failures, is how much applications adopt TCP-ENO-specific enhancements for endpoint authentication 👑✨

10. Security Considerations 💀

Okay bestie, this is the serious part, so let's get real 🫶. An obvious use case for TCP-ENO is opportunistic encryption, which means encrypting some connections, but only where it's supported and without any kind of endpoint authentication. Opportunistic encryption gives you a property called "opportunistic security" [RFC7435], which protects against undetectable large-scale eavesdropping. However, it does NOT protect against detectable large-scale eavesdropping 😭. For instance, if ISPs terminate TCP connections and proxy them, or just downgrade connections to unencrypted, the eavesdropping is visible. Moreover, opportunistic encryption emphatically does not protect against targeted attacks that use trivial spoofing to redirect a specific high-value connection to a man-in-the-middle attacker. So the mere presence of TEP-indicated encryption does not suffice for an application to represent a connection as secure to the user. Don't let your app slap a little lock icon on it just because ENO is there 🔒🙅‍♀️.

Achieving stronger security with TCP-ENO requires verifying session IDs ✨. Any application relying on ENO for communication security MUST incorporate session IDs into its endpoint authentication. For example, an authentication mechanism based on keyed digests, such as Digest Access Authentication [RFC7616], can be extended to include the role and session ID in the input of the keyed digest. Authentication mechanisms with a notion of channel binding, such as Salted Challenge Response Authentication Mechanism (SCRAM) [RFC5802], can be updated to derive a channel binding from the session ID. Higher-layer protocols MAY use the application-aware "a" bit to negotiate the inclusion of session IDs in authentication, even when there is no in-band way to carry out such a negotiation. Because there is only one "a" bit, though, a protocol extension that specifies use of the "a" bit will likely need a built-in versioning or negotiation mechanism to accommodate crypto agility and future updates 🦋.

Because TCP-ENO lets multiple different TEPs coexist, security could potentially be only as strong as the weakest available TEP 🥀. In particular, if TEPs use a weak hash function to incorporate the TCP-ENO transcript into session IDs, then an attacker can undetectably tamper with ENO options to force negotiation of a deprecated and vulnerable TEP. To avoid problems like that, security reviewers of new TEPs SHOULD pay particular attention to the collision resistance of hash functions used for session IDs, including the state of cryptanalysis and research into possible attacks 🔍. Even if other parts of a TEP rely on more esoteric cryptography that turns out to be vulnerable, it ought nonetheless to be intractable for an attacker to induce identical session IDs at both ends after tampering with ENO contents in SYN segments. Not a chance, bestie 🙅‍♀️.

Implementations MUST NOT send ENO options unless they have access to an adequate source of randomness [RFC4086]. Without secret unpredictable data at both ends of a connection, it is impossible for TEPs to achieve confidentiality and forward secrecy 💜. Systems typically have very little entropy on bootup, so implementations might need to disable TCP-ENO until after system initialization 🧚.

With a regular three-way handshake (meaning no simultaneous open), the non-SYN-form ENO option in an active opener's first ACK segment MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3 🎀. That data is not part of the TCP-ENO negotiation transcript, and therefore it MUST be separately authenticated by the TEP. Don't skip this part, it's the difference between a secure vibe and a total mess 💅.

11. IANA Considerations 🌸

This document defines a new TCP option kind for TCP-ENO, assigned a value of 69 from the TCP option space. The value is defined as follows:

  +------+--------+----------------------------------+-----------+
  | Kind | Length | Meaning                          | Reference |
  +------+--------+----------------------------------+-----------+
  | 69   | N      | Encryption Negotiation (TCP-ENO) | RFC 8547  |
  +------+--------+----------------------------------+-----------+

                  Table 2: TCP Option Kind Numbers

Early implementations of TCP-ENO and a predecessor TCP encryption protocol made unauthorized use of TCP option kind 69 🙈. These earlier uses of option 69 are not compatible with TCP-ENO and could disable encryption or cause complete connection failure when interoperating with TCP-ENO-compliant hosts. Hence, legacy use of option 69 MUST be disabled on hosts that cannot be upgraded to TCP-ENO. More recent implementations used experimental option 253 per [RFC6994] with 16-bit ExID 0x454E. Current and new implementations of TCP-ENO MUST use option 69, while any legacy implementations MUST migrate to option 69. Note in particular that Section 4.1 requires at most one SYN-form ENO option per segment, which means hosts MUST NOT include both option 69 and option 253 with ExID 0x454E in the same TCP segment. Option soup is a no-go 🚫🍓.

This document defines a 7-bit glt field in the range of 0x20-0x7f. IANA has created and will maintain a new registry titled "TCP Encryption Protocol Identifiers" under the "Transmission Control Protocol (TCP) Parameters" registry. Table 3 shows the initial contents of this registry. This document allocates one TEP identifier (0x20) for experimental use. In case the TEP identifier space proves too small, identifiers in the range 0x70-0x7f are reserved to enable a future update to this document to define extended identifier values. Future assignments are to be made upon satisfying either of two policies defined in [RFC8126]: "IETF Review" or (for non-IETF stream specifications) "Expert Review with RFC Required". IANA will furthermore provide early allocation [RFC7120] to facilitate testing before RFCs are finalized 🧪.

      +-----------+------------------------------+-----------+
      | Value     | Meaning                      | Reference |
      +-----------+------------------------------+-----------+
      | 0x20      | Experimental Use             | RFC 8547  |
      | 0x70-0x7f | Reserved for extended values | RFC 8547  |
      +-----------+------------------------------+-----------+

            Table 3: TCP Encryption Protocol Identifiers

12. References 📚

12.1. Normative References

[NIST-SP-800-57]
           National Institute of Standards and Technology,
           "Recommendation for Key Management - Part 1: General",
           NIST Special Publication, 800-57, Revision 4,
           DOI 10.6028/NIST.SP.800-57pt1r4, January 2016,
           <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
           NIST.SP.800-57pt1r4.pdf>.

[RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
           RFC 793, DOI 10.17487/RFC0793, September 1981,
           <https://www.rfc-editor.org/info/rfc793>.

[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>.

[RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
           "Randomness Requirements for Security", BCP 106, RFC 4086,
           DOI 10.17487/RFC4086, June 2005,
           <https://www.rfc-editor.org/info/rfc4086>.

[RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
           Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
           2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[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>.

12.2. Informative References

[RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
           Stevens, "Basic Socket Interface Extensions for IPv6",
           RFC 3493, DOI 10.17487/RFC3493, February 2003,
           <https://www.rfc-editor.org/info/rfc3493>.

[RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
           Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
           January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
           Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
           <https://www.rfc-editor.org/info/rfc4987>.

[RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
           Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
           <https://www.rfc-editor.org/info/rfc5116>.

[RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
           Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
           RFC 5382, DOI 10.17487/RFC5382, October 2008,
           <https://www.rfc-editor.org/info/rfc5382>.

[RFC5802]  Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
           "Salted Challenge Response Authentication Mechanism
           (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
           DOI 10.17487/RFC5802, July 2010,
           <https://www.rfc-editor.org/info/rfc5802>.

[RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
           Authentication of Named Entities (DANE)", RFC 6394,
           DOI 10.17487/RFC6394, October 2011,
           <https://www.rfc-editor.org/info/rfc6394>.

[RFC6994]  Touch, J., "Shared Use of Experimental TCP Options",
           RFC 6994, DOI 10.17487/RFC6994, August 2013,
           <https://www.rfc-editor.org/info/rfc6994>.

[RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
           Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
           <https://www.rfc-editor.org/info/rfc7413>.

[RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
           Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
           December 2014, <https://www.rfc-editor.org/info/rfc7435>.

[RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
           Digest Access Authentication", RFC 7616,
           DOI 10.17487/RFC7616, September 2015,
           <https://www.rfc-editor.org/info/rfc7616>.

[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>.

Acknowledgments 🫶

We are grateful for contributions, help, discussions, and feedback from the IETF and its TCPINC Working Group, including Marcelo Bagnulo, David Black, Bob Briscoe, Benoit Claise, Spencer Dawkins, Jake Holland, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson Ladd, Kathleen Moriarty, Yoav Nir, Christoph Paasch, Eric Rescorla, Adam Roach, Kyle Rose, Michael Scharf, Joe Touch, and Eric Vyncke. This work was partially funded by DARPA CRASH and the Stanford Secure Internet of Things Project. The whole squad really came through 💖.

Contributors 🎀

Dan Boneh was a coauthor of the draft that became this document 👑.

Authors' Addresses 💌

okay bestie, here are the 5 humans behind this whole thing, and yes they all deserve a shoutout 🫶

Andrea Bittau 🦋

Andrea Bittau
Google
345 Spear Street
San Francisco, CA  94105
United States of America

Email: bittau@google.com

Daniel B. Giffin 🌸

Daniel B. Giffin
Stanford University
353 Serra Mall, Room 288
Stanford, CA  94305
United States of America

Email: daniel@beech-grove.net

Mark Handley 🧚

Mark Handley
University College London
Gower St.
London  WC1E 6BT
United Kingdom

Email: M.Handley@cs.ucl.ac.uk

David Mazieres 💜

David Mazieres
Stanford University
353 Serra Mall, Room 290
Stanford, CA  94305
United States of America

Email: dm@uun.org

Eric W. Smith 🎀

Eric W. Smith
Kestrel Institute
3260 Hillview Avenue
Palo Alto, CA  94304
United States of America

Email: eric.smith@kestrel.edu

that's the whole squad, periodt 🌈👑 💅

📦 where this page comes from