From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8548.txt | 1795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1795 insertions(+) create mode 100644 doc/rfc/rfc8548.txt (limited to 'doc/rfc/rfc8548.txt') diff --git a/doc/rfc/rfc8548.txt b/doc/rfc/rfc8548.txt new file mode 100644 index 0000000..5c7d5e8 --- /dev/null +++ b/doc/rfc/rfc8548.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Bittau +Request for Comments: 8548 Google +Category: Experimental D. Giffin +ISSN: 2070-1721 Stanford University + M. Handley + University College London + D. Mazieres + Stanford University + Q. Slack + Sourcegraph + E. Smith + Kestrel Institute + May 2019 + + + Cryptographic Protection of TCP Streams (tcpcrypt) + +Abstract + + This document specifies "tcpcrypt", a TCP encryption protocol + designed for use in conjunction with the TCP Encryption Negotiation + Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating + resegmentation, NATs, and other manipulations of the TCP header. The + protocol is self-contained and specifically tailored to TCP + implementations, which often reside in kernels or other environments + in which large external software dependencies can be undesirable. + Because the size of TCP options is limited, the protocol requires one + additional one-way message latency to perform key exchange before + application data can be transmitted. However, the extra latency can + be avoided between two hosts that have recently established a + previous tcpcrypt connection. + + + + + + + + + + + + + + + + + + + + +Bittau, et al. Experimental [Page 1] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. 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). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8548. + +Copyright Notice + + Copyright (c) 2019 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) in effect on the date of + publication of this document. Please review these documents + carefully, as 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. + + + + + + + + + + + + + + + + + + + +Bittau, et al. Experimental [Page 2] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 + 3. Encryption Protocol . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Cryptographic Algorithms . . . . . . . . . . . . . . . . 4 + 3.2. Protocol Negotiation . . . . . . . . . . . . . . . . . . 6 + 3.3. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Session ID . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10 + 3.6. Data Encryption and Authentication . . . . . . . . . . . 14 + 3.7. TCP Header Protection . . . . . . . . . . . . . . . . . . 16 + 3.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.9. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . 17 + 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1. Key-Exchange Messages . . . . . . . . . . . . . . . . . . 18 + 4.2. Encryption Frames . . . . . . . . . . . . . . . . . . . . 20 + 4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2.2. Associated Data . . . . . . . . . . . . . . . . . . . 21 + 4.2.3. Frame ID . . . . . . . . . . . . . . . . . . . . . . 21 + 4.3. Constant Values . . . . . . . . . . . . . . . . . . . . . 22 + 5. Key-Agreement Schemes . . . . . . . . . . . . . . . . . . . . 22 + 6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 24 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 8.1. Asymmetric Roles . . . . . . . . . . . . . . . . . . . . 27 + 8.2. Verified Liveness . . . . . . . . . . . . . . . . . . . . 27 + 8.3. Mandatory Key-Agreement Schemes . . . . . . . . . . . . . 27 + 9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 10.2. Informative References . . . . . . . . . . . . . . . . . 30 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 + + + + + + + + + + + + + + + + +Bittau, et al. Experimental [Page 3] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +1. Introduction + + This document describes tcpcrypt, an extension to TCP for + cryptographic protection of session data. Tcpcrypt was designed to + meet the following goals: + + o Meet the requirements of the TCP Encryption Negotiation Option + (TCP-ENO) [RFC8547] for protecting connection data. + + o Be amenable to small, self-contained implementations inside TCP + stacks. + + o Minimize additional latency at connection startup. + + o As much as possible, prevent connection failure in the presence of + NATs and other middleboxes that might normalize traffic or + otherwise manipulate TCP segments. + + o Operate independently of IP addresses, making it possible to + authenticate resumed sessions efficiently even when either end + changes IP address. + + A companion document [TCPINC-API] describes recommended interfaces + for configuring certain parameters of this protocol. + +2. Requirements Language + + 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 interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Encryption Protocol + + This section describes the operation of the tcpcrypt protocol. The + wire format of all messages is specified in Section 4. + +3.1. Cryptographic Algorithms + + Setting up a tcpcrypt connection employs three types of cryptographic + algorithms: + + o A key agreement scheme is used with a short-lived public key to + agree upon a shared secret. + + + + + + +Bittau, et al. Experimental [Page 4] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + o An extract function is used to generate a pseudo-random key (PRK) + from some initial keying material produced by the key agreement + scheme. The notation Extract(S, IKM) denotes the output of the + extract function with salt S and initial keying material IKM. + + o A collision-resistant pseudo-random function (CPRF) is used to + generate multiple cryptographic keys from a pseudo-random key, + typically the output of the extract function. The CPRF produces + an arbitrary amount of Output Keying Material (OKM), and we use + the notation CPRF(K, CONST, L) to designate the first L bytes of + the OKM produced by the CPRF when parameterized by key K and the + constant CONST. + + The Extract and CPRF functions used by the tcpcrypt variants defined + in this document are the Extract and Expand functions of the HMAC- + based Key Derivation Function (HKDF) [RFC5869], which is built on + Keyed-Hashing for Message Authentication (HMAC) [RFC2104]. These are + defined as follows in terms of the function HMAC-Hash(key, value) for + a negotiated Hash function such as SHA-256; the symbol "|" denotes + concatenation, and the counter concatenated to the right of CONST + occupies a single octet. + + HKDF-Extract(salt, IKM) -> PRK + PRK = HMAC-Hash(salt, IKM) + + HKDF-Expand(PRK, CONST, L) -> OKM + T(0) = empty string (zero length) + T(1) = HMAC-Hash(PRK, T(0) | CONST | 0x01) + T(2) = HMAC-Hash(PRK, T(1) | CONST | 0x02) + T(3) = HMAC-Hash(PRK, T(2) | CONST | 0x03) + ... + + OKM = first L octets of T(1) | T(2) | T(3) | ... + where L <= 255*OutputLength(Hash) + + Figure 1: HKDF Functions Used for Key Derivation + + Lastly, once tcpcrypt has been successfully set up and encryption + keys have been derived, an algorithm for Authenticated Encryption + with Associated Data (AEAD) is used to protect the confidentiality + and integrity of all transmitted application data. AEAD algorithms + use a single key to encrypt their input data and also to generate a + cryptographic tag to accompany the resulting ciphertext; when + decryption is performed, the tag allows authentication of the + encrypted data and of optional associated plaintext data. + + + + + + +Bittau, et al. Experimental [Page 5] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +3.2. Protocol Negotiation + + Tcpcrypt depends on TCP-ENO [RFC8547] to negotiate whether encryption + will be enabled for a connection as well as which key-agreement + scheme to use. TCP-ENO negotiates the use of a particular TCP + encryption protocol (TEP) by including protocol identifiers in ENO + suboptions. This document associates four TEP identifiers with the + tcpcrypt protocol as listed in Table 4 of Section 7. Each identifier + indicates the use of a particular key-agreement scheme, with an + associated CPRF and length parameter. Future standards can associate + additional TEP identifiers with tcpcrypt following the assignment + policy specified by TCP-ENO. + + An active opener that wishes to negotiate the use of tcpcrypt + includes an ENO option in its SYN segment. That option includes + suboptions with tcpcrypt TEP identifiers indicating the key-agreement + schemes it is willing to enable. The active opener MAY additionally + include suboptions indicating support for encryption protocols other + than tcpcrypt, as well as global suboptions as specified by TCP-ENO. + + If a passive opener receives an ENO option including tcpcrypt TEPs + that it supports, it MAY then attach an ENO option to its SYN-ACK + segment, including solely the TEP it wishes to enable. + + To establish distinct roles for the two hosts in each connection, + tcpcrypt depends on the role-negotiation mechanism of TCP-ENO. As + one result of the negotiation process, TCP-ENO assigns hosts unique + roles abstractly called "A" at one end of the connection and "B" at + the other. Generally, an active opener plays the "A" role and a + passive opener plays the "B" role, but in the case of simultaneous + open, an additional mechanism breaks the symmetry and assigns a + distinct role to each host. TCP-ENO uses the terms "host A" and + "host B" to identify each end of a connection uniquely; this document + employs those terms in the same way. + + An ENO suboption includes a flag "v" which indicates the presence of + associated variable-length data. In order to propose fresh key + agreement with a particular tcpcrypt TEP, a host sends a one-byte + suboption containing the TEP identifier and v = 0. In order to + propose session resumption (described further below) with a + particular TEP, a host sends a variable-length suboption containing + the TEP identifier, the flag v = 1, an identifier derived from a + session secret previously negotiated with the same host and the same + TEP, and a nonce. + + + + + + + +Bittau, et al. Experimental [Page 6] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + Once two hosts have exchanged SYN segments, TCP-ENO defines the + negotiated TEP to be the last valid TEP identifier in the SYN segment + of host B (that is, the passive opener in the absence of simultaneous + open) that also occurs in that of host A. If there is no such TEP, + hosts MUST disable TCP-ENO and tcpcrypt. + + If the negotiated TEP was sent by host B with v = 0, it means that + fresh key agreement will be performed as described in Section 3.3. + If, on the other hand, host B sent the TEP with v = 1 and both hosts + sent appropriate resumption identifiers in their suboption data, then + the key-exchange messages will be omitted in favor of determining + keys via session resumption as described in Section 3.5. With + session resumption, protected application data MAY be sent + immediately as detailed in Section 3.6. + + Note that the negotiated TEP is determined without reference to the + "v" bits in ENO suboptions, so if host A offers resumption with a + particular TEP and host B replies with a non-resumption suboption + with the same TEP, that could become the negotiated TEP, in which + case fresh key agreement will be performed. That is, sending a + resumption suboption also implies willingness to perform fresh key + agreement with the indicated TEP. + + As REQUIRED by TCP-ENO, once a host has both sent and received an ACK + segment containing a valid ENO option, encryption MUST be enabled and + plaintext application data MUST NOT ever be exchanged on the + connection. If the negotiated TEP is among those listed in Table 4, + a host MUST follow the protocol described in this document. + +3.3. Key Exchange + + Following successful negotiation of a tcpcrypt TEP, all further + signaling is performed in the Data portion of TCP segments. Except + when resumption was negotiated (described in Section 3.5), the two + hosts perform key exchange through two messages, Init1 and Init2, at + the start of the data streams of host A and host B, respectively. + These messages MAY span multiple TCP segments and need not end at a + segment boundary. However, the segment containing the last byte of + an Init1 or Init2 message MUST have TCP's push flag (PSH) set. + + The key exchange protocol, in abstract, proceeds as follows: + + A -> B: Init1 = { INIT1_MAGIC, sym_cipher_list, N_A, Pub_A } + B -> A: Init2 = { INIT2_MAGIC, sym_cipher, N_B, Pub_B } + + The concrete format of these messages is specified in Section 4.1. + + + + + +Bittau, et al. Experimental [Page 7] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + The parameters are defined as follows: + + o INIT1_MAGIC, INIT2_MAGIC: Constants defined in Section 4.3. + + o sym_cipher_list: A list of identifiers of symmetric ciphers (AEAD + algorithms) acceptable to host A. These are specified in Table 5 + of Section 7. + + o sym_cipher: The symmetric cipher selected by host B from the + sym_cipher_list sent by host A. + + o N_A, N_B: Nonces chosen at random by hosts A and B, respectively. + + o Pub_A, Pub_B: Ephemeral public keys for hosts A and B, + respectively. These, as well as their corresponding private keys, + are short-lived values that MUST be refreshed frequently. The + private keys SHOULD NOT ever be written to persistent storage. + The security risks associated with the storage of these keys are + discussed in Section 8. + + If a host receives an ephemeral public key from its peer and a key- + validation step fails (see Section 5), it MUST abort the connection + and raise an error condition distinct from the end-of-file condition. + + The ephemeral secret ES is the result of the key-agreement algorithm + (see Section 5) indicated by the negotiated TEP. The inputs to the + algorithm are the local host's ephemeral private key and the remote + host's ephemeral public key. For example, host A would compute ES + using its own private key (not transmitted) and host B's public key, + Pub_B. + + The two sides then compute a pseudo-random key, PRK, from which all + session secrets are derived, as follows: + + PRK = Extract(N_A, eno_transcript | Init1 | Init2 | ES) + + Above, "|" denotes concatenation, eno_transcript is the protocol- + negotiation transcript defined in Section 4.8 of [RFC8547], and Init1 + and Init2 are the transmitted encodings of the messages described in + Section 4.1. + + A series of session secrets are computed from PRK as follows: + + ss[0] = PRK + ss[i] = CPRF(ss[i-1], CONST_NEXTK, K_LEN) + + + + + + +Bittau, et al. Experimental [Page 8] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + The value ss[0] is used to generate all key material for the current + connection. The values ss[i] for i > 0 are used by session + resumption to avoid public key cryptography when establishing + subsequent connections between the same two hosts as described in + Section 3.5. The CONST_* values are constants defined in + Section 4.3. The length K_LEN depends on the tcpcrypt TEP in use, + and is specified in Section 5. + + Given a session secret ss[i], the two sides compute a series of + master keys as follows: + + mk[0] = CPRF(ss[i], CONST_REKEY | sn[i], K_LEN) + mk[j] = CPRF(mk[j-1], CONST_REKEY, K_LEN) + + The process of advancing through the series of master keys is + described in Section 3.8. The values represented by sn[i] are + session nonces. For the initial session with i = 0, the session + nonce is zero bytes long. The values for subsequent sessions are + derived from fresh connection data as described in Section 3.5. + + Finally, each master key mk[j] is used to generate traffic keys for + protecting application data using authenticated encryption: + + k_ab[j] = CPRF(mk[j], CONST_KEY_A, ae_key_len + ae_nonce_len) + k_ba[j] = CPRF(mk[j], CONST_KEY_B, ae_key_len + ae_nonce_len) + + In the first session derived from fresh key agreement, traffic keys + k_ab[j] are used by host A to encrypt and host B to decrypt, while + keys k_ba[j] are used by host B to encrypt and host A to decrypt. In + a resumed session, as described more thoroughly in Section 3.5, each + host uses the keys in the same way as it did in the original session, + regardless of its role in the current session; for example, if a host + played role "A" in the first session, it will use keys k_ab[j] to + encrypt in each derived session. + + The values ae_key_len and ae_nonce_len depend on the authenticated- + encryption algorithm selected and are given in Table 3 of Section 6. + The algorithm uses the first ae_key_len bytes of each traffic key as + an authenticated-encryption key, and it uses the following + ae_nonce_len bytes as a nonce randomizer. + + Implementations SHOULD provide an interface allowing the user to + specify, for a particular connection, the set of AEAD algorithms to + advertise in sym_cipher_list (when playing role "A") and also the + order of preference to use when selecting an algorithm from those + offered (when playing role "B"). A companion document [TCPINC-API] + describes recommended interfaces for this purpose. + + + + +Bittau, et al. Experimental [Page 9] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + After host B sends Init2 or host A receives it, that host MAY + immediately begin transmitting protected application data as + described in Section 3.6. + + If host A receives Init2 with a sym_cipher value that was not present + in the sym_cipher_list it previously transmitted in Init1, it MUST + abort the connection and raise an error condition distinct from the + end-of-file condition. + + Throughout this document, to "abort the connection" means to issue + the "Abort" command as described in Section 3.8 of [RFC793]. That + is, the TCP connection is destroyed, RESET is transmitted, and the + local user is alerted to the abort event. + +3.4. Session ID + + TCP-ENO requires each TEP to define a session ID value that uniquely + identifies each encrypted connection. + + A tcpcrypt session ID begins with the byte transmitted by host B that + contains the negotiated TEP identifier along with the "v" bit. The + remainder of the ID is derived from the session secret and session + nonce, as follows: + + session_id[i] = TEP-byte | CPRF(ss[i], CONST_SESSID | sn[i], K_LEN) + + Again, the length K_LEN depends on the TEP and is specified in + Section 5. + +3.5. Session Resumption + + If two hosts have previously negotiated a session with secret + ss[i-1], they can establish a new connection without public-key + operations using ss[i], the next session secret in the sequence + derived from the original PRK. + + A host signals its willingness to resume with a particular session + secret by sending a SYN segment with a resumption suboption, i.e., an + ENO suboption containing the negotiated TEP identifier of the + previous session, half of the resumption identifier for the new + session, and a resumption nonce. + + The resumption nonce MUST have a minimum length of zero bytes and + maximum length of eight bytes. The value MUST be chosen randomly or + using a mechanism that guarantees uniqueness even in the face of + virtual-machine cloning or other re-execution of the same session. + An attacker who can force either side of a connection to reuse a + session secret with the same nonce will completely break the security + + + +Bittau, et al. Experimental [Page 10] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + of tcpcrypt. Reuse of session secrets is possible in the event of + virtual-machine cloning or reuse of system-level hibernation state. + Implementations SHOULD provide an API through which to set the + resumption nonce length and MUST default to eight bytes if they + cannot prohibit the reuse of session secrets. + + The resumption identifier is calculated from a session secret ss[i] + as follows: + + resume[i] = CPRF(ss[i], CONST_RESUME, 18) + + To name a session for resumption, a host sends either the first or + second half of the resumption identifier according to the role it + played in the original session with secret ss[0]. + + A host that originally played role "A" and wishes to resume from a + cached session sends a suboption with the first half of the + resumption identifier: + + byte 0 1 9 10 + +------+------+--...--+------+------+--...--+------+ + | TEP- | resume[i]{0..8} | nonce_a | + | byte | | | + +------+------+--...--+------+------+--...--+------+ + + Figure 2: Resumption suboption sent when original role was "A". + + The TEP-byte contains a tcpcrypt TEP identifier and v = 1. The nonce + value MUST have length between 0 and 8 bytes. + + Similarly, a host that originally played role "B" sends a suboption + with the second half of the resumption identifier: + + byte 0 1 9 10 + +------+------+--...--+------+------+--...--+------+ + | TEP- | resume[i]{9..17} | nonce_b | + | byte | | | + +------+------+--...--+------+------+--...--+------+ + + Figure 3: Resumption suboption sent when original role was "B". + + The TEP-byte contains a tcpcrypt TEP identifier and v = 1. The nonce + value MUST have length between 0 and 8 bytes. + + If a passive opener receives a resumption suboption containing an + identifier-half that names a session secret that it has cached, and + the subobtion's TEP matches the TEP used in the previous session, it + SHOULD (with exceptions specified below) agree to resume from the + + + +Bittau, et al. Experimental [Page 11] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + cached session by sending its own resumption suboption, which will + contain the other half of the identifier. Otherwise, it MUST NOT + agree to resumption. + + If a passive opener does not agree to resumption with a particular + TEP, it MAY either request fresh key exchange by responding with a + non-resumption suboption using the same TEP or else respond to any + other received TEP suboption. + + If a passive opener receives an ENO suboption with a TEP identifier + and v = 1, but the suboption data is less than 9 bytes in length, it + MUST behave as if the same TEP had been sent with v = 0. That is, + the suboption MUST be interpreted as an offer to negotiate fresh key + exchange with that TEP. + + If an active opener sends a resumption suboption with a particular + TEP and the appropriate half of a resumption identifier, and then, in + the same TCP handshake, it receives a resumption suboption with the + same TEP and an identifier-half that does not match that resumption + identifier, it MUST ignore that suboption. In the typical case that + this was the only ENO suboption received, this means the host MUST + disable TCP-ENO and tcpcrypt; it MUST NOT send any more ENO options + and MUST NOT encrypt the connection. + + When a host concludes that TCP-ENO negotiation has succeeded for some + TEP that was received in a resumption suboption, it MUST then enable + encryption with that TEP using the cached session secret. To do + this, it first constructs sn[i] as follows: + + sn[i] = nonce_a | nonce_b + + Master keys are then computed from s[i] and sn[i] as described in + Section 3.3 as well as from application data encrypted as described + in Section 3.6. + + The session ID (Section 3.4) is constructed in the same way for + resumed sessions as it is for fresh ones. In this case, the first + byte will always have v = 1. The remainder of the ID is derived from + the cached session secret and the session nonce that was generated + during resumption. + + In the case of simultaneous open where TCP-ENO is able to establish + asymmetric roles, two hosts that simultaneously send SYN segments + with compatible resumption suboptions MAY resume the associated + session. + + In a particular SYN segment, a host SHOULD NOT send more than one + resumption suboption (because this consumes TCP option space and is + + + +Bittau, et al. Experimental [Page 12] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + unlikely to be a useful practice), and it MUST NOT send more than one + resumption suboption with the same TEP identifier. But in addition + to any resumption suboptions, an active opener MAY include + non-resumption suboptions describing other TEPs it supports (in + addition to the TEP in the resumption suboption). + + After using the session secret ss[i] to compute mk[0], + implementations SHOULD compute and cache ss[i+1] for possible use by + a later session and then erase ss[i] from memory. Hosts MAY retain + ss[i+1] until it is used or the memory needs to be reclaimed. Hosts + SHOULD NOT write any session secrets to non-volatile storage. + + When proposing resumption, the active opener MUST use the lowest + value of "i" that has not already been used (successfully or not) to + negotiate resumption with the same host and for the same original + session secret ss[0]. + + A given session secret ss[i] MUST NOT be used to secure more than one + TCP connection. To prevent this, a host MUST NOT resume with a + session secret if it has ever enabled encryption in the past with the + same secret, in either role. In the event that two hosts + simultaneously send SYN segments to each other that propose + resumption with the same session secret but with both segments not + part of a simultaneous open, both connections would need to revert to + fresh key exchange. To avoid this limitation, implementations MAY + choose to implement session resumption such that all session secrets + derived from a given ss[0] are used for either passive or active + opens at the same host, not both. + + If two hosts have previously negotiated a tcpcrypt session, either + host MAY later initiate session resumption regardless of which host + was the active opener or played the "A" role in the previous session. + + However, a given host MUST either encrypt with keys k_ab[j] for all + sessions derived from the same original session secret ss[0], or with + keys k_ba[j]. Thus, which keys a host uses to send segments is not + affected by the role it plays in the current connection: it depends + only on whether the host played the "A" or "B" role in the initial + session. + + Implementations that cache session secrets MUST provide a means for + applications to control that caching. In particular, when an + application requests a new TCP connection, it MUST have a way to + specify two policies for the duration of the connection: 1) that + resumption requests will be ignored, and thus fresh key exchange will + be necessary; and 2) that no session secrets will be cached. (These + policies can be specified independently or as a unit.) And for an + established connection, an application MUST have a means to cause any + + + +Bittau, et al. Experimental [Page 13] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + cache state that was used in or resulted from establishing the + connection to be flushed. A companion document [TCPINC-API] + describes recommended interfaces for this purpose. + +3.6. Data Encryption and Authentication + + Following key exchange (or its omission via session resumption), all + further communication in a tcpcrypt-enabled connection is carried out + within delimited encryption frames that are encrypted and + authenticated using the agreed-upon keys. + + This protection is provided via algorithms for Authenticated + Encryption with Associated Data (AEAD). The permitted algorithms are + listed in Table 5 of Section 7. Additional algorithms can be + specified in the future according to the policy in that section. One + algorithm is selected during the negotiation described in + Section 3.3. The lengths ae_key_len and ae_nonce_len associated with + each algorithm are found in Table 3 of Section 6 along with + requirements for which algorithms MUST be implemented. + + The format of an encryption frame is specified in Section 4.2. A + sending host breaks its stream of application data into a series of + chunks. Each chunk is placed in the data field of a plaintext value, + which is then encrypted to yield a frame's ciphertext field. Chunks + MUST be small enough that the ciphertext (whose length depends on the + AEAD cipher used, and is generally slightly longer than the + plaintext) has length less than 2^16 bytes. + + An "associated data" value (see Section 4.2.2) is constructed for the + frame. It contains the frame's control field and the length of the + ciphertext. + + A "frame ID" value (see Section 4.2.3) is also constructed for the + frame, but not explicitly transmitted. It contains a 64-bit offset + field whose integer value is the zero-indexed byte offset of the + beginning of the current encryption frame in the underlying TCP + datastream. (That is, the offset in the framing stream, not the + plaintext application stream.) The offset is then left-padded with + zero-valued bytes to form a value of length ae_nonce_len. Because it + is strictly necessary for the security of the AEAD algorithms + specified in this document, an implementation MUST NOT ever transmit + distinct frames with the same frame ID value under the same + encryption key. In particular, a retransmitted TCP segment MUST + contain the same payload bytes for the same TCP sequence numbers, and + a host MUST NOT transmit more than 2^64 bytes in the underlying TCP + datastream (which would cause the offset field to wrap) before + rekeying as described in Section 3.8. + + + + +Bittau, et al. Experimental [Page 14] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + Keys for AEAD encryption are taken from the traffic key k_ab[j] or + k_ba[j] for some "j", according to the host's role as described in + Section 3.3. First, the appropriate traffic key is divided into two + parts: + + ae_key_len + ae_nonce_len - 1 + | + byte 0 ae_key_len | + | | | + v v v + +----+----+--...--+----+----+----+--...--+----+ + | K | NR | + +----+----+--...--+----+----+----+--...--+----+ + + Figure 4: Format of Traffic Key + + With reference to the "AEAD Interface" described in Section 2 of + [RFC5116], the first ae_key_len bytes of the traffic key provide the + AEAD key K. The remaining ae_nonce_len bytes provide a nonce + randomizer value NR, which is combined via bitwise exclusive-or with + the frame ID to yield N, the AEAD nonce for the frame: + + N = frame_ID XOR NR + + The remaining AEAD inputs, P and A, are provided by the frame's + plaintext value and associated data, respectively. The output of the + AEAD operation, C, is transmitted in the frame's ciphertext field. + + When a frame is received, tcpcrypt reconstructs the associated data + and frame ID values (the former contains only data sent in the clear, + and the latter is implicit in the TCP stream), computes the nonce N + as above, and provides these and the ciphertext value to the AEAD + decryption operation. The output of this operation is either a + plaintext value P or the special symbol FAIL. In the latter case, + the implementation SHOULD abort the connection and raise an error + condition distinct from the end-of-file condition. But if none of + the TCP segment(s) containing the frame have been acknowledged and + retransmission could potentially result in a valid frame, an + implementation MAY instead drop these segments (and renege if they + have been selectively acknowledged (SACKed), according to Section 8 + of [RFC2018]). + + + + + + + + + + +Bittau, et al. Experimental [Page 15] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +3.7. TCP Header Protection + + The ciphertext field of the encryption frame contains protected + versions of certain TCP header values. + + When the URGp bit is set, the urgent field indicates an offset from + the current frame's beginning offset; the sum of these offsets gives + the index of the last byte of urgent data in the application + datastream. + + A sender MUST set the FINp bit on the last frame it sends in the + connection (unless it aborts the connection) and MUST NOT set FINp on + any other frame. + + TCP sets the FIN flag when a sender has no more data, which with + tcpcrypt means setting FIN on the segment containing the last byte of + the last frame. However, a receiver MUST report the end-of-file + condition to the connection's local user when and only when it + receives a frame with the FINp bit set. If a host receives a segment + with the TCP FIN flag set but the received datastream including this + segment does not contain a frame with FINp set, the host SHOULD abort + the connection and raise an error condition distinct from the end-of- + file condition. But if there are unacknowledged segments whose + retransmission could potentially result in a valid frame, the host + MAY instead drop the segment with the TCP FIN flag set (and renege if + it has been SACKed, according to Section 8 of [RFC2018]). + +3.8. Rekeying + + Rekeying allows hosts to wipe from memory keys that could decrypt + previously transmitted segments. It also allows the use of AEAD + ciphers that can securely encrypt only a bounded number of messages + under a given key. + + As described in Section 3.3, a master key mk[j] is used to generate + two encryption keys k_ab[j] and k_ba[j]. We refer to these as a key + set with generation number "j". Each host maintains both a local + generation number that determines which key set it uses to encrypt + outgoing frames and a remote generation number equal to the highest + generation used in frames received from its peer. Initially, these + two generation numbers are set to zero. + + A host MAY increment its local generation number beyond the remote + generation number it has recorded. We call this action "initiating + rekeying". + + + + + + +Bittau, et al. Experimental [Page 16] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + When a host has incremented its local generation number and uses the + new key set for the first time to encrypt an outgoing frame, it MUST + set rekey = 1 for that frame. It MUST set rekey = 0 in all other + cases. + + When a host receives a frame with rekey = 1, it increments its record + of the remote generation number. If the remote generation number is + now greater than the local generation number, the receiver MUST + immediately increment its local generation number to match. + Moreover, if the receiver has not yet transmitted a segment with the + FIN flag set, it MUST immediately send a frame (with empty + application data if necessary) with rekey = 1. + + A host MUST NOT initiate more than one concurrent rekey operation if + it has no data to send; that is, it MUST NOT initiate rekeying with + an empty encryption frame more than once while its record of the + remote generation number is less than its own. + + Note that when parts of the datastream are retransmitted, TCP + requires that implementations always send the same data bytes for the + same TCP sequence numbers. Thus, frame data in retransmitted + segments MUST be encrypted with the same key as when it was first + transmitted, regardless of the current local generation number. + + Implementations SHOULD delete older-generation keys from memory once + they have received all frames they will need to decrypt with the old + keys and have encrypted all outgoing frames under the old keys. + +3.9. Keep-Alive + + Instead of using TCP keep-alives to verify that the remote endpoint + is still responsive, tcpcrypt implementations SHOULD employ the + rekeying mechanism for this purpose, as follows. When necessary, a + host SHOULD probe the liveness of its peer by initiating rekeying and + transmitting a new frame immediately (with empty application data if + necessary). + + As described in Section 3.8, a host receiving a frame encrypted under + a generation number greater than its own MUST increment its own + generation number and (if it has not already transmitted a segment + with FIN set) immediately transmit a new frame (with zero-length + application data if necessary). + + Implementations MAY use TCP keep-alives for purposes that do not + require endpoint authentication, as discussed in Section 8.2. + + + + + + +Bittau, et al. Experimental [Page 17] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +4. Encodings + + This section provides byte-level encodings for values transmitted or + computed by the protocol. + +4.1. Key-Exchange Messages + + The Init1 message has the following encoding: + + byte 0 1 2 3 + +-------+-------+-------+-------+ + | INIT1_MAGIC | + | | + +-------+-------+-------+-------+ + + 4 5 6 7 + +-------+-------+-------+-------+ + | message_len | + | = M | + +-------+-------+-------+-------+ + + 8 + +--------+-----+----+-----+----+---...---+-----+-----+ + |nciphers|sym_ |sym_ | |sym_ | + | = K |cipher[0] |cipher[1] | |cipher[K-1]| + +--------+-----+----+-----+----+---...---+-----+-----+ + + 2*K + 9 2*K + 9 + N_A_LEN + | | + v v + +-------+---...---+-------+-------+---...---+-------+ + | N_A | Pub_A | + | | | + +-------+---...---+-------+-------+---...---+-------+ + + M - 1 + +-------+---...---+-------+ + | ignored | + | | + +-------+---...---+-------+ + + The constant INIT1_MAGIC is defined in Section 4.3. The four-byte + field message_len gives the length of the entire Init1 message, + encoded as a big-endian integer. The nciphers field contains an + integer value that specifies the number of two-byte symmetric-cipher + identifiers that follow. The sym_cipher[i] identifiers indicate + + + + + +Bittau, et al. Experimental [Page 18] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + cryptographic algorithms in Table 5 in Section 7. The length N_A_LEN + and the length of Pub_A are both determined by the negotiated TEP as + described in Section 5. + + Implementations of this protocol MUST construct Init1 such that the + ignored field has zero length; that is, they MUST construct the + message such that its end, as determined by message_len, coincides + with the end of the field Pub_A. When receiving Init1, however, + implementations MUST permit and ignore any bytes following Pub_A. + + The Init2 message has the following encoding: + + byte 0 1 2 3 + +-------+-------+-------+-------+ + | INIT2_MAGIC | + | | + +-------+-------+-------+-------+ + + + 4 5 6 7 8 9 + +-------+-------+-------+-------+-------+-------+ + | message_len | sym_cipher | + | = M | | + +-------+-------+-------+-------+-------+-------+ + + 10 10 + N_B_LEN + | | + v v + +-------+---...---+-------+-------+---...---+-------+ + | N_B | Pub_B | + | | | + +-------+---...---+-------+-------+---...---+-------+ + + M - 1 + +-------+---...---+-------+ + | ignored | + | | + +-------+---...---+-------+ + + The constant INIT2_MAGIC is defined in Section 4.3. The four-byte + field message_len gives the length of the entire Init2 message, + encoded as a big-endian integer. The sym_cipher value is a selection + from the symmetric-cipher identifiers in the previously-received + Init1 message. The length N_B_LEN and the length of Pub_B are both + determined by the negotiated TEP as described in Section 5. + + + + + + +Bittau, et al. Experimental [Page 19] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + Implementations of this protocol MUST construct Init2 such that the + field "ignored" has zero length; that is, they MUST construct the + message such that its end, as determined by message_len, coincides + with the end of the Pub_B field. When receiving Init2, however, + implementations MUST permit and ignore any bytes following Pub_B. + +4.2. Encryption Frames + + An encryption frame comprises a control byte and a length-prefixed + ciphertext value: + + byte 0 1 2 3 clen+2 + +-------+-------+-------+-------+---...---+-------+ + |control| clen | ciphertext | + +-------+-------+-------+-------+---...---+-------+ + + The field clen is an integer in big-endian format and gives the + length of the ciphertext field. + + The control field has this structure: + + bit 7 1 0 + +-------+---...---+-------+-------+ + | cres | rekey | + +-------+---...---+-------+-------+ + + The seven-bit field cres is reserved; implementations MUST set these + bits to zero when sending and MUST ignore them when receiving. + + The use of the rekey field is described in Section 3.8. + +4.2.1. Plaintext + + The ciphertext field is the result of applying the negotiated + authenticated-encryption algorithm to a plaintext value, which has + one of these two formats: + + byte 0 1 plen-1 + +-------+-------+---...---+-------+ + | flags | data | + +-------+-------+---...---+-------+ + + + byte 0 1 2 3 plen-1 + +-------+-------+-------+-------+---...---+-------+ + | flags | urgent | data | + +-------+-------+-------+-------+---...---+-------+ + + + + +Bittau, et al. Experimental [Page 20] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + (Note that clen in the previous section will generally be greater + than plen, as the ciphertext produced by the authenticated-encryption + scheme both encrypts the application data and provides redundancy + with which to verify its integrity.) + + The flags field has this structure: + + bit 7 6 5 4 3 2 1 0 + +----+----+----+----+----+----+----+----+ + | fres |URGp|FINp| + +----+----+----+----+----+----+----+----+ + + The six-bit field fres is reserved; implementations MUST set these + six bits to zero when sending, and MUST ignore them when receiving. + + When the URGp bit is set, it indicates that the urgent field is + present, and thus that the plaintext value has the second structure + variant above; otherwise, the first variant is used. + + The meaning of the urgent field and of the flag bits is described in + Section 3.7. + +4.2.2. Associated Data + + An encryption frame's associated data (which is supplied to the AEAD + algorithm when decrypting the ciphertext and verifying the frame's + integrity) has this format: + + byte 0 1 2 + +-------+-------+-------+ + |control| clen | + +-------+-------+-------+ + + It contains the same values as the frame's control and clen fields. + +4.2.3. Frame ID + + Lastly, a frame ID (used to construct the nonce for the AEAD + algorithm) has this format: + + byte 0 ae_nonce_len - 8 ae_nonce_len - 1 + | | | + v v v + +-----+--...--+-----+-----+--...--+-----+ + | 0 | | 0 | offset | + +-----+--...--+-----+-----+--...--+-----+ + + + + + +Bittau, et al. Experimental [Page 21] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + The 8-byte offset field contains an integer in big-endian format. + Its value is specified in Section 3.6. Zero-valued bytes are + prepended to the offset field to form a structure of length + ae_nonce_len. + +4.3. Constant Values + + The table below defines values for the constants used in the + protocol. + + +------------+--------------+ + | Value | Name | + +------------+--------------+ + | 0x01 | CONST_NEXTK | + | 0x02 | CONST_SESSID | + | 0x03 | CONST_REKEY | + | 0x04 | CONST_KEY_A | + | 0x05 | CONST_KEY_B | + | 0x06 | CONST_RESUME | + | 0x15101a0e | INIT1_MAGIC | + | 0x097105e0 | INIT2_MAGIC | + +------------+--------------+ + + Table 1: Constant Values Used in the Protocol + +5. Key-Agreement Schemes + + The TEP negotiated via TCP-ENO indicates the use of one of the key- + agreement schemes named in Table 4 in Section 7. For example, + TCPCRYPT_ECDHE_P256 names the tcpcrypt protocol using ECDHE-P256 + together with the CPRF and length parameters specified below. + + All the TEPs specified in this document require the use of HKDF- + Expand-SHA256 as the CPRF, and these lengths for nonces and session + secrets: + + N_A_LEN: 32 bytes + N_B_LEN: 32 bytes + K_LEN: 32 bytes + + Future documents assigning additional TEPs for use with tcpcrypt + might specify different values for the lengths above. Note that the + minimum session ID length specified by TCP-ENO, together with the way + tcpcrypt constructs session IDs, implies that K_LEN MUST have length + at least 32 bytes. + + Key-agreement schemes ECDHE-P256 and ECDHE-P521 employ the Elliptic + Curve Secret Value Derivation Primitive, Diffie-Hellman version + + + +Bittau, et al. Experimental [Page 22] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + (ECSVDP-DH) defined in [IEEE-1363]. The named curves are defined in + [NIST-DSS]. When the public-key values Pub_A and Pub_B are + transmitted as described in Section 4.1, they are encoded with the + "Elliptic Curve Point to Octet String Conversion Primitive" described + in Section E.2.3 of [IEEE-1363] and are prefixed by a two-byte length + in big-endian format: + + byte 0 1 2 L - 1 + +-------+-------+-------+---...---+-------+ + | pubkey_len | pubkey | + | = L | | + +-------+-------+-------+---...---+-------+ + + Implementations MUST encode these pubkey values in "compressed + format". Implementations MUST validate these pubkey values according + to the algorithm in Section A.16.10 of [IEEE-1363]. + + Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 perform the + Diffie-Hellman protocol using the functions X25519 and X448, + respectively. Implementations SHOULD compute these functions using + the algorithms described in [RFC7748]. When they do so, + implementations MUST check whether the computed Diffie-Hellman shared + secret is the all-zero value and abort if so, as described in + Section 6 of [RFC7748]. Alternative implementations of these + functions SHOULD abort when either input forces the shared secret to + one of a small set of values as discussed in Section 7 of [RFC7748]. + + For these schemes, public-key values Pub_A and Pub_B are transmitted + directly with no length prefix: 32 bytes for ECDHE-Curve25519 and 56 + bytes for ECDHE-Curve448. + + Table 2 below specifies the requirement levels of the four TEPs + specified in this document. In particular, all implementations of + tcpcrypt MUST support TCPCRYPT_ECDHE_Curve25519. However, system + administrators MAY configure which TEPs a host will negotiate + independent of these implementation requirements. + + +-------------+---------------------------+ + | Requirement | TEP | + +-------------+---------------------------+ + | REQUIRED | TCPCRYPT_ECDHE_Curve25519 | + | RECOMMENDED | TCPCRYPT_ECDHE_Curve448 | + | OPTIONAL | TCPCRYPT_ECDHE_P256 | + | OPTIONAL | TCPCRYPT_ECDHE_P521 | + +-------------+---------------------------+ + + Table 2: Requirements for Implementation of TEPs + + + + +Bittau, et al. Experimental [Page 23] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +6. AEAD Algorithms + + This document uses sym_cipher identifiers in the messages Init1 and + Init2 (see Section 3.3) to negotiate the use of AEAD algorithms; the + values of these identifiers are given in Table 5 in Section 7. The + algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM are specified in + [RFC5116]. The algorithm AEAD_CHACHA20_POLY1305 is specified in + [RFC8439]. + + Implementations MUST support certain AEAD algorithms according to + Table 3. Note that system administrators MAY configure which + algorithms a host will negotiate independently of these requirements. + + Lastly, this document uses the lengths ae_key_len and ae_nonce_len to + specify aspects of encryption and data formats. These values depend + on the negotiated AEAD algorithm, also according to the table below. + + +------------------------+-------------+------------+--------------+ + | AEAD Algorithm | Requirement | ae_key_len | ae_nonce_len | + +------------------------+-------------+------------+--------------+ + | AEAD_AES_128_GCM | REQUIRED | 16 bytes | 12 bytes | + | AEAD_AES_256_GCM | RECOMMENDED | 32 bytes | 12 bytes | + | AEAD_CHACHA20_POLY1305 | RECOMMENDED | 32 bytes | 12 bytes | + +------------------------+-------------+------------+--------------+ + + Table 3: Requirement and Lengths for Each AEAD Algorithm + +7. IANA Considerations + + For use with TCP-ENO's negotiation mechanism, tcpcrypt's TEP + identifiers have been incorporated in IANA's "TCP Encryption Protocol + Identifiers" registry under the "Transmission Control Protocol (TCP) + Parameters" registry, as in Table 4. The various key-agreement + schemes used by these tcpcrypt variants are defined in Section 5. + + +-------+---------------------------+-----------+ + | Value | Meaning | Reference | + +-------+---------------------------+-----------+ + | 0x21 | TCPCRYPT_ECDHE_P256 | [RFC8548] | + | 0x22 | TCPCRYPT_ECDHE_P521 | [RFC8548] | + | 0x23 | TCPCRYPT_ECDHE_Curve25519 | [RFC8548] | + | 0x24 | TCPCRYPT_ECDHE_Curve448 | [RFC8548] | + +-------+---------------------------+-----------+ + + Table 4: TEP Identifiers for Use with tcpcrypt + + In Section 6, this document defines the use of several AEAD + algorithms for encrypting application data. To name these + + + +Bittau, et al. Experimental [Page 24] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + algorithms, the tcpcrypt protocol uses two-byte identifiers in the + range 0x0001 to 0xFFFF, inclusively, for which IANA maintains a new + "tcpcrypt AEAD Algorithms" registry under the "Transmission Control + Protocol (TCP) Parameters" registry. The initial values for this + registry are given in Table 5. 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 | AEAD Algorithm | Reference | + +--------+------------------------+----------------------+ + | 0x0001 | AEAD_AES_128_GCM | [RFC8548], Section 6 | + | 0x0002 | AEAD_AES_256_GCM | [RFC8548], Section 6 | + | 0x0010 | AEAD_CHACHA20_POLY1305 | [RFC8548], Section 6 | + +--------+------------------------+----------------------+ + + Table 5: Authenticated-Encryption Algorithms for Use with tcpcrypt + +8. Security Considerations + + All of the security considerations of TCP-ENO apply to tcpcrypt. In + particular, tcpcrypt does not protect against active network + attackers unless applications authenticate the session ID. If it can + be established that the session IDs computed at each end of the + connection match, then tcpcrypt guarantees that no man-in-the-middle + attacks occurred unless the attacker has broken the underlying + cryptographic primitives, e.g., Elliptic Curve Diffie-Hellman (ECDH). + A proof of this property for an earlier version of the protocol has + been published [tcpcrypt]. + + To ensure middlebox compatibility, tcpcrypt does not protect TCP + headers. Therefore, the protocol is vulnerable to denial-of-service + from off-path attackers just as plain TCP is. Possible attacks + include desynchronizing the underlying TCP stream, injecting RST or + FIN segments, and forging rekey bits. These attacks will cause a + tcpcrypt connection to hang or fail with an error, but not in any + circumstance where plain TCP could continue uncorrupted. + Implementations MUST give higher-level software a way to distinguish + such errors from a clean end-of-stream (indicated by an authenticated + FINp bit) so that applications can avoid semantic truncation attacks. + + There is no "key confirmation" step in tcpcrypt. This is not needed + because tcpcrypt's threat model includes the possibility of a + connection to an adversary. If key negotiation is compromised and + yields two different keys, failed integrity checks on every + subsequent frame will cause the connection either to hang or to + + + +Bittau, et al. Experimental [Page 25] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + abort. This is not a new threat as an active attacker can achieve + the same results against a plain TCP connection by injecting RST + segments or modifying sequence and acknowledgement numbers. + + Tcpcrypt uses short-lived public keys to provide forward secrecy; + once an implementation removes these keys from memory, a compromise + of the system will not provide any means to derive the session + secrets for past connections. All currently-specified key agreement + schemes involve key agreement based on Ephemeral Elliptic Curve + Diffie-Hellman (ECDHE), meaning a new key pair can be efficiently + computed for each connection. If implementations reuse these + parameters, they MUST limit the lifetime of the private parameters as + far as is practical in order to minimize the number of past + connections that are vulnerable. Of course, placing private keys in + persistent storage introduces severe risks that they will not be + destroyed reliably and in a timely fashion, and it SHOULD be avoided + whenever possible. + + Attackers cannot force passive openers to move forward in their + session resumption chain without guessing the content of the + resumption identifier, which will be difficult without key knowledge. + + The cipher-suites specified in this document all use HMAC-SHA256 to + implement the collision-resistant pseudo-random function denoted by + CPRF. A collision-resistant function is one for which, for + sufficiently large L, an attacker cannot find two distinct inputs + (K_1, CONST_1) and (K_2, CONST_2) such that CPRF(K_1, CONST_1, L) = + CPRF(K_2, CONST_2, L). Collision resistance is important to assure + the uniqueness of session IDs, which are generated using the CPRF. + + Lastly, many of tcpcrypt's cryptographic functions require random + input, and thus any host implementing tcpcrypt MUST have access to a + cryptographically-secure source of randomness or pseudo-randomness. + [RFC4086] provides recommendations on how to achieve this. + + Most implementations will rely on a device's pseudo-random generator, + seeded from hardware events and a seed carried over from the previous + boot. Once a pseudo-random generator has been properly seeded, it + can generate effectively arbitrary amounts of pseudo-random data. + However, until a pseudo-random generator has been seeded with + sufficient entropy, not only will tcpcrypt be insecure, it will + reveal information that further weakens the security of the pseudo- + random generator, potentially harming other applications. As + REQUIRED by TCP-ENO, implementations MUST NOT send ENO options unless + they have access to an adequate source of randomness. + + + + + + +Bittau, et al. Experimental [Page 26] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + +8.1. Asymmetric Roles + + Tcpcrypt transforms a shared pseudo-random key (PRK) into + cryptographic traffic keys for each direction. Doing so requires an + asymmetry in the protocol, as the key derivation function must be + perturbed differently to generate different keys in each direction. + Tcpcrypt includes other asymmetries in the roles of the two hosts, + such as the process of negotiating algorithms (e.g., proposing vs. + selecting cipher suites). + +8.2. Verified Liveness + + Many hosts implement TCP keep-alives [RFC1122] as an option for + applications to ensure that the other end of a TCP connection still + exists even when there is no data to be sent. A TCP keep-alive + segment carries a sequence number one prior to the beginning of the + send window and may carry one byte of "garbage" data. Such a segment + causes the remote side to send an acknowledgment. + + Unfortunately, tcpcrypt cannot cryptographically verify keep-alive + acknowledgments. Therefore, an attacker could prolong the existence + of a session at one host after the other end of the connection no + longer exists. (Such an attack might prevent a process with + sensitive data from exiting, giving an attacker more time to + compromise a host and extract the sensitive data.) + + To counter this threat, tcpcrypt specifies a way to stimulate the + remote host to send verifiably fresh and authentic data, described in + Section 3.9. + + The TCP keep-alive mechanism has also been used for its effects on + intermediate nodes in the network, such as preventing flow state from + expiring at NAT boxes or firewalls. As these purposes do not require + the authentication of endpoints, implementations MAY safely + accomplish them using either the existing TCP keep-alive mechanism or + tcpcrypt's verified keep-alive mechanism. + +8.3. Mandatory Key-Agreement Schemes + + This document mandates that tcpcrypt implementations provide support + for at least one key-agreement scheme: ECDHE using Curve25519. This + choice of a single mandatory algorithm is the result of a difficult + tradeoff between cryptographic diversity and the ease and security of + actual deployment. + + The IETF's appraisal of best current practice on this matter + [RFC7696] says, "Ideally, two independent sets of mandatory-to- + implement algorithms will be specified, allowing for a primary suite + + + +Bittau, et al. Experimental [Page 27] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + and a secondary suite. This approach ensures that the secondary + suite is widely deployed if a flaw is found in the primary one." + + To meet that ideal, it might appear natural to also mandate ECDHE + using P-256. However, implementing the Diffie-Hellman function using + NIST elliptic curves (including those specified for use with + tcpcrypt, P-256 and P-521) appears to be very difficult to achieve + without introducing vulnerability to side-channel attacks + [NIST-fail]. Although well-trusted implementations are available as + part of large cryptographic libraries, these can be difficult to + extract for use in operating-system kernels where tcpcrypt is usually + best implemented. In contrast, the characteristics of Curve25519 + together with its recent popularity has led to many safe and + efficient implementations, including some that fit naturally into the + kernel environment. + + [RFC7696] insists that, "The selected algorithms need to be resistant + to side-channel attacks and also meet the performance, power, and + code size requirements on a wide variety of platforms." On this + principle, tcpcrypt excludes the NIST curves from the set of + mandatory-to-implement key-agreement algorithms. + + Lastly, this document encourages support for key agreement with + Curve448, categorizing it as RECOMMENDED. Curve448 appears likely to + admit safe and efficient implementations. However, support is not + REQUIRED because existing implementations might not yet be + sufficiently well proven. + +9. Experiments + + Some experience will be required to determine whether the tcpcrypt + protocol can be deployed safely and successfully across the diverse + environments of the global internet. + + Safety means that TCP implementations that support tcpcrypt are able + to communicate reliably in all the same settings as they would + without tcpcrypt. As described in Section 9 of [RFC8547], this + property can be subverted if middleboxes strip ENO options from + non-SYN segments after allowing them in SYN segments, or if the + particular communication patterns of tcpcrypt offend the policies of + middleboxes doing deep-packet inspection. + + Success, in addition to safety, means hosts that implement tcpcrypt + actually enable encryption when connecting to one another. This + property depends on the network's treatment of the TCP-ENO handshake + and can be subverted if middleboxes merely strip unknown TCP options + or terminate TCP connections and relay data back and forth + unencrypted. + + + +Bittau, et al. Experimental [Page 28] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + Ease of implementation will be a further challenge to deployment. + Because tcpcrypt requires encryption operations on frames that may + span TCP segments, kernel implementations are forced to buffer + segments in different ways than are necessary for plain TCP. More + implementation experience will show how much additional code + complexity is required in various operating systems and what kind of + performance effects can be expected. + +10. References + +10.1. Normative References + + [IEEE-1363] + IEEE, "IEEE Standard Specifications for Public-Key + Cryptography", IEEE Standard 1363-2000, + DOI 10.1109/IEEESTD.2000.92292. + + [NIST-DSS] National Institute of Standards and Technology (NIST), + "Digital Signature Standard (DSS)", FIPS PUB 186-4, + DOI 10.6028/NIST.FIPS.186-4, July 2013. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + . + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, + DOI 10.17487/RFC2018, October 1996, + . + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + DOI 10.17487/RFC2104, February 1997, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated + Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, + . + + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + . + + + +Bittau, et al. Experimental [Page 29] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code + Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January + 2014, . + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, . + + [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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, + . + + [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and + E. Smith, "TCP-ENO: Encryption Negotiation Option", + RFC 8547, DOI 10.17487/RFC8547, May 2019, + . + +10.2. Informative References + + [NIST-fail] + Bernstein, D. and T. Lange, "Failures in NIST's ECC + Standards", January 2016, + . + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + . + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . + + [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm + Agility and Selecting Mandatory-to-Implement Algorithms", + BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, + . + + + + +Bittau, et al. Experimental [Page 30] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + [tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and + D. Boneh, "The case for ubiquitous transport-level + encryption", USENIX Security Symposium, August 2010. + + [TCPINC-API] + Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres, + D., and E. Smith, "Interface Extensions for TCP-ENO and + tcpcrypt", Work in Progress, draft-ietf-tcpinc-api-06, + June 2018. + +Acknowledgments + + We are grateful for contributions, help, discussions, and feedback + from the TCPINC Working Group and from other IETF reviewers, + including Marcelo Bagnulo, David Black, Bob Briscoe, Jana Iyengar, + Stephen Kent, Tero Kivinen, Mirja Kuhlewind, Yoav Nir, Christoph + Paasch, Eric Rescorla, Kyle Rose, and Dale Worley. + + This work was funded by gifts from Intel (to Brad Karp) and from + Google; by NSF award CNS-0716806 (A Clean-Slate Infrastructure for + Information Flow Control); by DARPA CRASH under contract + #N66001-10-2-4088; and by the Stanford Secure Internet of Things + Project. + +Contributors + + Dan Boneh and Michael Hamburg were coauthors of the draft that became + this document. + +Authors' Addresses + + Andrea Bittau + Google + 345 Spear Street + San Francisco, CA 94105 + United States of America + + Email: bittau@google.com + + + + + + + + + + + + + +Bittau, et al. Experimental [Page 31] + +RFC 8548 tcpcrypt: TCP Encryption Protocol May 2019 + + + Daniel B. Giffin + Stanford University + 353 Serra Mall, Room 288 + Stanford, CA 94305 + United States of America + + Email: daniel@beech-grove.net + + + Mark Handley + University College London + Gower St. + London WC1E 6BT + United Kingdom + + Email: M.Handley@cs.ucl.ac.uk + + + David Mazieres + Stanford University + 353 Serra Mall, Room 290 + Stanford, CA 94305 + United States of America + + Email: dm@uun.org + + + Quinn Slack + Sourcegraph + 121 2nd St Ste 200 + San Francisco, CA 94105 + United States of America + + Email: sqs@sourcegraph.com + + + Eric W. Smith + Kestrel Institute + 3260 Hillview Avenue + Palo Alto, CA 94304 + United States of America + + Email: eric.smith@kestrel.edu + + + + + + + + +Bittau, et al. Experimental [Page 32] + -- cgit v1.2.3