]> Akamai Technologies

erik+ietf@nygren.org

Akamai Technologies

mbishop@evequefou.be

WIT httpbis HRS Request Smuggling Message Binding HTTP/1.1 Message Binding adds new hop-by-hop header fields that are cryptographically bound to requests and responses. The use of this protocol is negotiated out-of-band from the HTTP datastream, and keys can be communicated either in-band in the first request or out-of-band (such as via TLS Exporters). These header fields allow endpoints to detect and mitigate desynchronization attacks, such as HTTP Request Smuggling, that exist due to datastream handling differences.

Introduction

Motivation HTTP Request Smuggling is a class of desynchronization attack where a malicious endpoint can cause a chain of other endpoints to get confused about HTTP request framing due to attributes of the HTTP/1.1 protocol leading to ambiguities in interpretation and variations in implementation. For example, if in a flow of: Intermediary => Origin Server ]]> the User Agent can send an HTTP request header field with two Content-Length header fields and a Body that contains a second smuggled HTTP request after one of the content lengths. If the Intermediary and Origin Server interpret the request in different ways, the Intermediary might think that there was one request while the Origin Server thinks there are now two requests. Not only would the first request get smuggled past Intermediary defenses, if there is a second real request (so a total of three requests if you include the smuggled one) then the Intermediary might cache the contents of the smuggled response with the cache key of the third request. There are nigh-infinite variations on this class of attack against HTTP/1.1 with frequent vulnerabilities being found and fixed. While some of these are implemenation bugs, others are due to underspecification in the HTTP/1.1 protocol itself. This latter case is hard for any single party to fix, hence where this specification can act as an additonal line of defense. While HTTP/2 and HTTP/3 are better ( ), conversions between HTTP versions can also be vectors for vulnerabilities here to creep in. Additionally, a malicious User Agent could force an HTTP/1.1 connection to pollute shared resources (a cache or persistent connection) shared with other User Agents using newer HTTP protocols. Furthermore, the simplicity of HTTP/1.1 and large legacy code bases mean that there is extensive use of HTTP/1.1 in Intermediaries such as reverse proxies in the ecosystem: Origin Servers themselves may have an implementation where an Intermediary proxy fronts application servers, each of which having distinct HTTP implementations potentially from different vendors.

Threat Model This specification is specifically aimed at reducing the cases where a User Agent can influence the behavior between an Intermediary (an Upstream Server) and a Downstream Server (which may be an Origin Server or another Intermediary). Concretely, the following are intended to be defended against:

• T1. The User Agent smuggling a request past an Intermediary (Upstream Server) to a Downstream Server in a way that the Upstream and Downstream Servers become desynchronized on which requests they are processing.
• T2. The User Agent exploiting desynchronization vulnerabilities to receive the response payload not intended for it (in the case where the Upstream to Downstream Server connection is multiplexed and contains requests beyond just those belonging to the User Agent).
• T3. The User Agent exploiting smuggling vulnerabilities to get the Downstream Server to process a request bypassing policy enforcements from the Upstream Server
• T4. The user agent exploiting smuggling vulnerabilities to get the Downstream Server to process a request that includes header fields supplied by a malicious User Agent but which were supposed to have been hop-by-hop headers supplied by the Intermediary (such as those supposedly annotating authentication results).
• T5. The User Agent exploiting implementation vulnerabilities in the parsing of HTTP/1.1's equivalents of HTTP/2 pseudo-headers (authority, path, and method) to bypass policy controls on an Upstream Server or to get a Downstream Server to differently interpret the request due to smuggled header field or body contents.
• T6. The User Agent exploiting this specification to cause communication failures between an Upstream Server and a Downstream Server for the case where the Downstream Server has implemented this specification but the Upstream Server has not, meaning that the Upstream Server passes through the hop-by-hop headers defined here without removing them.

This specification is NOT intended to defend against:

• N1. Protecting communications between a User Agent and an Intermediary. User Agents are assumed to always be potentially hostile.
• N2. Acting as a primary security control that obviates the need for proper implementations. It is intended only to act as a secondary stop-gap to mitigate vulnerabilities.
• N3. Protecting against actors who can intercept, view, or modify communications between the Upstream Server and Downstream Server.
• N5. Protecting User Agents or Upstream Servers against malicious or compromised Downstream Servers.
• N4. Protecting against actors who have control over an Upstream Server or a Downstream Server, although this specification may help in some cases to contain attacks where a hostile Upstream Server is communicating to a Downstream Server which in-turn is communicating to another Downstream Server.

Mitigation Overview The key concept of this specification is for HTTP/1.1 endpoints (such as an Intermediary and an Origin Server) to be able to share information about their state (e.g., which request/response they think they're parsing) in a way that is cryptographically bound to the hop-by-hop series of requests (ie, either to the TLS connection or to keying information passed in the first request). Since the attacker has no access to the key used for the cryptographic binding, this allows the endpoints to detect desynchronization and fail out but without needing changes to the HTTP/1.1 protocol itself. This shared key is then used to authenticate newly introduced hop-by-hop header fields, binding information in those header fields (which includes sequential request/response serial numbers) to the request. Cases where requests or responses do become desynchronized will be detected due to invalid bound header fields (either due to failing to validate or not matching what is expected). While "Request Framing Confusion" attacks (such as HTTP Request Smuggling or HRS) are one of the most common forms of HTTP Processing Discrepancy attacks, other types of attacks such as Host Confusion can also cause problems (). This specification focuses on the former, but as it evolves we may be able to extend the approach taken to defend against other forms of attacks such as Host Confusion and Path Confusion, as well as to protect header fields added by Intermediaries. (FOR DISCUSSION: How broadly do we want to scope this specification? How much do we include here, and how much do we leave hooks to enable future extension? At the moment this is intentionally in a middle-ground, and we may either want to simplify or make more general.) The use of Message Binding header fields is negotiated during the TLS handshake (or may be statically configured for cases where communications between and configuration for the Upstream and Downstream Servers are tightly controlled). Multiple mechanisms then exist for key exchange: 1) The cipher suite and keying information may be sent as a hop-by-hop header field for the first request on a connection. 2) HTTP endpoints communicating HTTPS over TLS may use TLS Exporters to obtain the key used for the binding ( ), enabling both endpoints of a connection to securely derive this key out-of-band from the request flow in a way that can't be tampered with. 3) As the key used for the binding is abstracted out, proprietary implementations not using TLS can distribute the key in some other manner, such as in a preface attribute that could be added to the PROXY protocol .

Illustrative Example In an example HRS attack from a malicious User Agent to an Origin Server through an Intermediary, the request might start out normally but the malicious User Agent smuggles a second malicious request into the initial request (e.g., due to a bug in the Intermediary or due to the Intermediary and Origin Server interpreting the HTTP/1.1 protocol slightly differently). (TODO: Add a diagram) The net result is that the Intermediary and Origin Server get desynchronized as to how requests and responses line up. When the malicious User Agent makes a second request, it gets back the response to the smuggled request, and a caching Intermediary may actually cache the response to the smuggled request with the cache key of this second request. This means the attacker can not only bypass any controls the Intermediary may be implementing, but may also be able to poison its cache. With the proposed mitigation, the Intermediary augments the first and second requests (from its perspective) with cryptographically protected hop-by-hop Bound-Request header fields indicating a serial number (e.g., 1 and 2). While the Origin Server is able to validate the header field in the first request, the smuggled request is missing the header field (and even if the attacker tried to add one it would fail validation due to the attacker not having the cryptographic secret). This allows the Origin Server to detect the desynchronization, enabling it to refuse to process the smuggled request and terminate the connection. (TODO: Add a diagram) Request Smuggling is a family of attacks with many variations. This is why it's valuable to include the request and response binding hop-by-hop header fields in both directions, as in some other variations it might be possible for things to get reordered such that an Intermediary making request A with serial=1 might get back a response for a request C with serial=2 and needs to be able to fail on that as well, as well as any wide range of other similar cases of desynchronization. The need for a cryptographic binding to the channel between the Intermediary and Downstream Server (e.g., with TLS Exporters) is required to prevent the malicious User Agent from including a fake request binding header field in what is being smuggled in (which by its nature may be invisible to the Intermediary due to some bug or vulnerability).

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document uses terms defined in , including "Client", "Server", "Intermediary", "Origin", "upstream", "downstream", "inbound", and "outbound".

Bound Message Header Protocol This specification introduces new hop-by-hop Bound-Request-Init, Bound-Request, and Bound-Response message header fields, which use structured fields. These header fields convey a request/response Serial number, additional attributes, and a cryptographic binding. As these are hop-by-hop header fields they are added by the endpoints on the HTTP/1.1 persistent connection (). Below we refer to the outbound endpoint making the request as the Intermediary () and the inbound endpoint receiving the request and issuing a response as the Downstream Server. The Downstream Server may be either another Intermediary or an Origin Server. Intermediaries and Downstream Servers MUST NOT exchange Bound-Request-Init, Bound-Request, or Bound-Response header fields unless they have mutually negotiated this protocol, either as described below in or via some other out-of-band mechanism. If the User Agent and Downstream Server have negotiated using this protocol for a connection, the Upstream Server MUST send a Bound-Request-Init header field on the first request (and only the first request) on that connection. If the User Agent and Downstream Server have negotiated using this protocol for a connection, they MUST also send Bound-Request and Bound-Response header fields in all requests and responses on that connection.

Request/Response Serials The Request Serial ($req_serial) is a counter starting at 1 for the initial request in an HTTP/1.1 persistent connection, and then incrementing by 1 for each subsequent request. The Response Serial ($resp_serial) for a response is then reflected back to match the Request Serial from the corresponding request.

Binding Mechanism The Binding Mechanism specifies how the Binding Key is derived as well as the cryptographic function used to bind requests. A list of mechanisms and associated keys is sent by the Upstream Server in its first request in a Bound-Request-Init header field. The server selects one of the offered mechanisms and echoes that choice back on every subsequent Bound-Response via a mechanism parameter, so that the Upstream Server can unambiguously determine which construction was used for the lifetime of the connection. The initial registry of mechanism names includes:

• inband-hmac-sha256 -- HMAC-SHA256 () keyed with a 256 bit (32 octet) key value carried inband in the key parameter.
• exporter-hmac-sha256 -- HMAC-SHA256 using a key derived from a TLS exporter, as described in . The key parameter for this mechanism is unused and MUST be omitted, since the actual key comes from the TLS exporter.
• inband-siphash -- SipHash () keyed with the 128 bit (16 octet) key value carried inband in the key parameter. This uses SipHash-2-4 with 64 bit (8 octet) output.

Unless explicitly negotiated and configured out-of-band, inband-hmac-sha256 is mandatory to implement and MUST be used in the Bound-Request for the first request on a connection. (TODO: Determine which of these is Mandatory to Implement as well as which to use for the Bound-Request in the first request. It may make sense for the TLS handshake to be able to negotiate exporter-hmac-sha256 in which case that is the only one used.) (TODO: Add an IANA registry section for these.) (FOR DISCUSSION: Which of these do we want to include? With hardware acceleration, hmac-sha256 may perform close enough to siphash to not be worth including both. We could consider AES-GMAC-128 since the keys must be unique but that has its own risks on nonce reuse so it would be critical that the nonce was a function of direction+serial. Using a non-cryptographic function might reduce the overhead but would make the security properties considerably harder to reason about.)

Binding Key The Binding Key is a binary cryptographic value that is associated with the connection. Below we will refer to the binding key for requests as $req_key and the binding key for responses as $resp_key. With HTTPS over TLS and exporter-hmac-sha256 the binding keys MUST be derived as described in .

Bound-Request-Init Header Specification The Bound-Request-Init header field is sent by the Upstream Server only on the first request of a connection. Its value is a Structured Fields List () whose members are Tokens identifying a supported mechanism, each parameterized with an initial key for that mechanism. Where:

• mechanism-name is one of the supported mechanisms listed in
• mechanism-key is the corresponding key to use if that mechanism is selected.

An Upstream Server MUST list at least one mechanism, and MAY list more than one mechanism in order of preference, most-preferred first. A client MUST supply a distinct key for each mechanism that requires an inband key, and MUST generate these keys using a cryptographically secure random number generator. Keys carried in Bound-Request-Init are scoped to the connection on which they are sent and MUST NOT be reused across connections. For example, a Upstream Server offering all three mechanisms might send:

Bound-Request and Bound-Response Header Specification The Bound-Request and Bound-Response header fields are specified as an integer item (the Serial) followed by a parameter list of items. The ABNF is as follows: (TODO: restructure the ABNF to allow the parameter orders to vary) The binding value for a request or response with a given key is constructed as: In the above:

• $serial is the request or response serial as a string
• $direction is the string req for the Bound-Request header or resp for Bound-Response header
• $method is the HTTP request method associated with the request
• $authority is the authority ((as defined in ) from the normalized URI (as defined in ) for the request and MUST match the value in the request's Host header field
• $path is the path ((as defined in ) from the normalized URI (as defined in ) for the request and MUST match the value from the the URI following normalization.
• $response_code is the response code for the response

The $function and $key for the for binding_value varies based on the mechanism:

• For inband-hmac-sha256, the $function is HMAC-SHA256 () keyed with the key parameter sent with the Bound-Request-Init.
• For inband-siphash, the $function is SipHash-2-4 () with 64-bit output and keyed with the key parameter sent with the Bound-Request-Init.
• For exporter-hmac-sha256 the $function is HMAC-SHA256 using a $key derived from a TLS exporter, as described in . The $key is either $req_key or $resp_key depending on if this is a request or response.

(TODO: better specify how to normalize the path and the path matching rules) For example, the header field added to the first request on a connection might be:

For Discussion: Additional Attributes to Bind? FOR DISCUSSION: Do we want to add in additional information to defend against additional sorts of attacks? Would we want to change how we encode these? The reasons to include attributes into the Message Binding are:

• Information from an Intermediary or Origin Server endpoint is intermixed in the bytestream with information that was sourced from a potentially malicious User Agent. HTTP/2 and HTTP/3 use distinct pseudoheaders to encode some of these separately, but other header fields such as Client-Cert () have no such protections.
• The encoding within HTTP/1.1 is underspecified in ways that lead to ambiguity, such as with variations in Path and Host header field parsing.

Some options might include:

• Adding the :path as a parameter (or adding an attribute indicating that it should be considered included) and also binding it in. This new draft version proposes that, but it is still under-specified.
• Having a way to more generally encode HTTP/2 pseudoheader field values in a way that is less ambiguous (converted to sf-binary?) and gets bound in.
• Including a list of header fields to bind in, and then use HTTP Message Signatures or similar to protect them. This would be particularly useful for protecting header fields such as Client-Cert.

Adding more in does add more complexity and has more risks of compatibility issues. It may also be worth considering going the other direction and removing method and authority parameters.

Intermediary Request Handling Intermediaries which have negotiated this protocol MUST add a Bound-Request-Init header field to the first request on a connection listing the mechanisms that it supports. Intermediaries which have negotiated this protocol MUST add a Bound-Request header field with each request they make. The $req_serial MUST start at 1 for the first request on a persistent connection, and MUST be incremented by 1 for each subsequent request. If the Intermediary is an Intermediary, regardless of whether or not this protocol was negotiated for the connection, it MUST remove any Bound-Request and Bound-Request-Init header fields that it received (prior to adding its own, if applicable). The mechanism used in the Bound-Request header field for the first request on a connection MUST match a mechanism included in the Bound-Request-Init header field. This mechanism MUST be one that the Downstream Server is known to support, either as negotiated during the TLS handshake, as the mandatory-to-implement inband-hmac-sha256, or statically configured out-of-band. The mechanism used in all but the first Bound-Request header fields MUST match the mechanism returned by the Downstream Server in its first Bound-Response.

Downstream Server Request Handling A Downstream Server that receives a Bound-Request-Init header field MUST select exactly one of the offered mechanisms and reflect that choice on the corresponding and all subsequent Bound-Response header fields on the connection. If the Downstream Server does not support any of the offered mechanisms, it MUST terminate the connection. A Downstream Server MUST terminate the connection if it receives a Bound-Request-Init header field on any request other than the first request of a connection. A Downstream Server MUST terminate the connection if this specification was negotiated but the first request on the connection does not include the Bound-Request-Init header field. A Downstream Server MUST terminate the connection if this specification was NOT negotiated but a Bound-Request-Init header field was received in any request. Downstream Servers which have negotiated this protocol MUST validate the presence and contents of the Bound-Request header field prior to processing a request. Any failures MUST be detected early in request processing (such as during request parsing), and Downstream Servers MUST immediately terminate the connection without returning an error response. Validation checks MUST include:

• Confirmation that the Bound-Request header field is present
• Confirmation that the cryptographic binding hash matches what was expected
• Confirmation that the $req_serial matches what was expected, starting at 1 for the first request on the connection and incrementing by 1 for each subsequent request
• Confirmation that the authority and method and path match those in the request

If the Server is an Intermediary, it MUST remove the Bound-Request and Bound-Request-Init header fields before constructing a request to the upstream hop, regardless of whether this protocol was used on the downstream connection. When constructing a response to an HTTP request the Downstream Server MUST add a Bound-Response header field with a $resp_serial matching the $req_serial of the incoming request. If the Server is an Intermediary, it MUST first remove any Bound-Response header fields that it received, regardless of whether this protocol was used on the upstream connection.

Intermediary Response Handling Intermediaries which have negotiated this protocol MUST validate the presence and contents of the Bound-Response header field prior to processing a response. Any failures MUST be detected early in response processing (such as during response parsing), and Intermediaries MUST immediately terminate the connection without processing any data from the response. Validation checks MUST include:

• Confirmation that the Bound-Response header field is present
• Confirmation that the cryptographic binding MAC matches what was expected
• Confirmation that the $resp_serial matches the $req_serial of the request that the response is in-response to.
• Confirmation that the authority and method and path match those from the corresponding request
• Confirmation that the $response_code matches that from the response (or interim response, as discussed in )

The Intermediary MUST remove the Bound-Response header field before constructing a response to the downstream connection, regardless of whether this protocol is used for the downstream connection.

Handling 100 Continue and 103 Early Hints When using 100 Continue and 103 Early Hints, the $req_serial and $resp_serial MUST remain the same and match for all interim and final responses. Each interim response MUST contain a Bound-Response header field with a response-code parameter matching the response code of the interim response. (TODO can we safely extend this requirement to all 1xx status codes?)

Retrying Requests Requests which are retried MUST be treated no differently than other forms of request, with their $req_serial coming from the order of the request in a persistent connection. If a request is retried over a different connection a new Bound-Request header field MUST be reconstructed corresponding to the new connection.

Handling TLS 1.3 Early Data TODO: define how this works with TLS 1.3 0RTT as it adds additional wrinkles. While this maybe could be made to work there (e.g., using the separate early exporter secret and potentially a distinct space for request_serials) , we need to ensure that we properly handle situations where an HTTP request spans 0-RTT and 1-RTT data.

Use with HTTPS over TLS and TLS Exporters

Negotiation Since the Bound-Request and Bound-Request-Init header fields are hop-by-hop header fields they are not safe to send unless the Intermediary knows that recipient supports them, will process them, and then will remove them. Intermediaries and Downstream Servers MUST NOT send Bound-Request or Bound-Request-Init or Bound-Response header fields on connections where they have not negotiated this protocol. Negotiation needs to happen out-of-band (e.g., at the TLS layer) due to the nature of the attacks this is trying to mitigate. Options for negotiation include:

• A modification to the ALPN (eg, http/1.1-bound-inband or http/1.1-bound-exporter). This may be the lowest-effort lift to retrofit into existing legacy HTTP/1.1 applications (which is the target use-case for this specification) as it requires no changes to the TLS library. This is recommended for interop testing of initial experimental implementations.
• ALPS (stalled/expired)
• TLS Extension Flags (waiting on implementation)
• An all-new TLS extension specific to this purpose, which could also make it easier to version this protocol.

Note that the first two options only support TLS 1.3 between the Intermediary and Downstream Server. It would also be preferable for the mechanism here to negotiate the supported versions of this protocol, such as if cryptographic agility or additional functionality is needed. Application Protocols (ALPN values, per ) other than http/1.1 are not supported, and a Downstream Server MUST NOT negotiate this Request-Binding protocol when negotiating an application protocol other than http/1.1.

Key Derivation using TLS Exporters When exporter-hmac-sha256 is used, the $req_key and $resp_key are derived using TLS Exporters.

• For TLS 1.3 this is specified in
• For TLS 1.2 this is specified in

Endpoints MAY support TLS 1.2 using , but if they do they MUST only use this extension when the extended master secret () extension is also used. Endpoints MUST NOT use this protocol for versions of TLS prior to 1.2. The request and response keys are constructed for a connection with: The added context ensures that we get different keys derived for different negotiated ALPNs. When HTTP/1.1 was negotiated without an ALPN, $alpn SHALL be http/1.1. When this extension is negotiated, HTTP requests that indicate an HTTP-version other than HTTP/1.1 MUST be rejected, with the connection closed prior to sending an HTTP-layer response.

Security Considerations

Handling detection of desynchronized connections When an endpoint detects desynchronization (due to a missing or invalid Message Binding header field) it needs to consider itself to be in an unknown, inconsistent, and potentially adversary-controlled state. Any processing that happens past this point for this or other requests on the connection is dangerous and suspect, as nothing in the connection bytestream can be trusted at this point. Letting the request or response get past validation failures during parsing would leave the endpoint vulnerable and might execute smuggled instructions. Returning an HTTP error response would be bad as this response would be desynchronized and could be cached. While breaking the connection does not provide information to Intermediaries as to why things broke, it is imperative to terminate immediately. TODO: explore if there may be a way to use a TLS alert to signal that badness happened to the other endpoint.

Logging failures Endpoints SHOULD log information indicating why the request or connection failed. Even more care than usual needs to be taken handling information received as there is no way to distinguish information as having come from a potentially trusted Intermediary vs having come from a malicious adversary. Downstream Servers logging information from detected smuggled requests need to take care as all information is suspect. It is critical that validation (and fail-out) happens very early in handling the request, such as during the request/response parsing itself. Even logging things from the smuggled request must be handled very carefully.

Use of keys negotiated out-of-band With the use of TLS Exporters each connection gets a unique pair of $req_key and $resp_key. With the use of inband mechanisms, a unique key is sent in the first request on the connection. If an alternate mechanism is used by proprietary implementations to exchange these keys then they MUST be unique per connection. Otherwise an attacker who can get a request header reflected back from one connection might be able to replay it in another connection.

Leakage of key communicated inband When inband-* mechanisms are used there is a risk that a Downsteam Server might return back the contents of the Bound-Request-Init header. If this were to happen, a malicious User Agent could forge subsequent Bound-Request headers and defeat the protections of this specification. Servers implementing this specification MUST take care to not leak the contents of the Bound-Request-Init header (such as through diagnostic features or error responses). The use of exporter-* mechanisms defends against this risk and is thus RECOMMENDED given the nature of the vulnerabilities this specification aims to defend against.

Potentially weak cryptography with SipHash is used The use of the inband-siphash mechanism is only appropriate for the use of this as a secondary defense against implementation vulnerabilities. It is likely NOT appropriate if other information with primary security control properties is bound into the request.

Privacy considerations Due to this protocol primarily being used between Intermediaries and Downstream Servers, information sent by the Intermediary during the TLS handshake for negotiation does not cause privacy issues for end-users. If this protocol were to be extended into end-user User Agents as well, more evaluation of privacy considerations would be warranted.

IANA Considerations TODO: Add IANA considerations for the HTTP Headers, for TLS Exporter labels, and for the TLS extension details used for negotiation.

References Normative References This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. Informative References This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner. Google Google This document describes a Transport Layer Security (TLS) extension for negotiating application-layer protocol settings (ALPS) within the TLS handshake. Any application-layer protocol operating over TLS can use this mechanism to indicate its settings to the peer in parallel with the TLS handshake completion. Dell Technologies A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. HAProxy Technologies Northeastern University

Appendix: Alternate Approaches and Similar Protocols TLS Exporters are used in other protocols such as (Exported Authenticators in TLS). While it is meant as a building block, it requires round-trips for some scenarios which would make it not suitable here.

Appendix: Bikeshed Topics Some details to work through include:

• Should the starting serial be 1 or 0?

Acknowledgments The authors would like to thank Kaan Onarlioglu, Rich Salz, Benjamin Kaduk, Uttaran Dutta, and others who have contributed to this proposal.