]> Google LLC

dschinazi.ietf@gmail.com

Web and Internet Transport HTTP oblivious HTTP configuration extension Oblivious HTTP is a protocol for forwarding encrypted HTTP messages. This requires communicating the gateway's key configuration to clients. While a key configuration media type was defined for this purpose, it has some limitations such as the inability to convey key lifetimes and interoperability issues. This document defines a similar extensible key configuration format that addresses those issues. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Working Group information can be found at . Source for this draft and an issue tracker can be found at .

Introduction Oblivious HTTP () is a protocol for forwarding encrypted HTTP messages. This requires communicating the gateway's key configuration to clients. A key configuration media type was defined for this purpose in . That format has the following limitations.

Key Lifetimes The security properties of OHTTP rely on periodic rotation of gateway keys. Many gateways rotate their keys on a weekly cadence. However, the original key configuration format has no way of informing the client of the lifetime of the keys it contains. Clients then need to assume an expiration time; if they didn't, they might keep using keys past when the gateway forgot them, or worse: they might encrypt sensitive data using a key that leaked after its expiration. Since those bounds aim to be conservative, clients can end up marking a key as expired even though it is still fresh on the gateway. This reduces reliability when periodic key fetch operations fail due to intermittent connectivity issues.

Interoperability Issues During the development of , the authors discovered a forward compatibility issue with the key configuration format: parsing multiple keys required explicit support for each included KEM because the length of the HPKE public key was not encoded in the format. This would prevent deploying new KEMs in a backwards-compatible way. The authors resolved this by adding a length prefix to each configuation entry. Unfortunately, they did not change the media type when doing so. Since this change to the format was made after the document's working group last call, there were already implementations in production. At the time of writing, there are multiple billions of devices in production that understand the "application/ohttp-keys" media type as not including the length prefix. Other client implementations support both formats by attempting to parse with the length prefix and falling back to the older format if that fails. This runs the risk of segregating clients, as described in .

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 terminology from . Where this document defines protocol types, the definition format uses the notation from . This specification uses the variable-length integer encoding from . Variable-length integer values do not need to be encoded in the minimum number of bytes necessary.

Extensible Format This document defines a new media type (see for its value). It represents a list of key configurations. It has the following format:

A List of Key Configurations

The "HPKE Symmetric Algorithms" struct consists of the following fields:

HPKE KDF ID:

A 16 bit HPKE KDF identifier as defined in or the HPKE KDF IANA registry.

HPKE AEAD ID:

A 16 bit HPKE AEAD identifier as defined in or the HPKE AEAD IANA registry.

The "Extension" struct consists of the following fields:

Extension ID:

A 62 bit OHTTP Key Configuration Extension identifier as defined in .

Extension Length:

The length of the "Extension Value" field that follows it.

Extension Value:

Extension-specific information, with encoding rules dependent on the value of the "Extension ID" field.

The "Key Config" struct consists of the following fields:

Key Config Length:

A 16 bit integer in network byte order that encodes the length, in bytes, of this "Key Config" struct, not including this field.

Key Identifier:

An 8 bit value that identifies the key used by the Oblivious Gateway Resource.

HPKE KEM ID:

A 16 bit value that identifies the Key Encapsulation Method (KEM) used for the identified key as defined in or the HPKE KDF IANA registry.

HPKE Public Key:

The public key used by the gateway. The length of the public key is Npk, which is determined by the choice of HPKE KEM as defined in .

HPKE Symmetric Algorithms Length:

A 16 bit integer in network byte order that encodes the length, in bytes, of the HPKE Symmetric Algorithms field that follows.

HPKE Symmetric Algorithms:

One or more "HPKE Symmetric Algorithms" structs.

Extensions:

Zero or more "Extension" structs. This field continues until the end of this "Key Config" struct.

The new media type defined in this document represents a list of concatenated "Key Config" structs.

Extensions In addition to providing an extensible format for OHTTP key configurations, this document defines two extensions. The EXPIRATION extension indicates the date/time after which the key can no longer be used. The NOT_BEFORE extension indicates the date/time before which the key cannot yet be used. Both are encoded as QUIC variable-length integers representing UNIX timestamps (number of seconds since January 1, 1970, UTC -- see ). The NOT_BEFORE extension allows a gateway to publish public keys in advance of them being valid. Given that and the EXPIRATION extension, the bounds can then be tightenned on the validity of keys, increasing both security and reliability. Gateways SHOULD provide some leeway between their stated times and the actual times to account for a few minutes of clock skew.

Parsing When parsing the list of key configurations, clients MUST silently skip any key configuration that carries a KEM ID unknown to the client. Clients MUST also silently skip over any extension for which the extension ID is unknown. As mentioned in , a client that receives an list of key configuration object with encoding errors might be able to recover one or more key configurations. Differences in how key configurations are recovered might be exploited to segregate clients, so clients MUST discard the entire list if they encounter any encoding error in one of the key configurations or its extensions. If an Extension Value field contains more data than expected for that Extension ID, the client MUST treat it as an encoding error. If the Extension Length field is such that the extension would extend past the end of the Key Config struct, clients MUST treat it as an encoding error.

Security Considerations The security considerations described in apply to this document as well.

IANA Considerations

Media Type The "application/ohttp-keys-ext-00" media type identifies a key configuration used by Oblivious HTTP. Note that the sybtype is expected to be changed if non-backwards-compatible changes are made to the format. If this document is approved, the "-NN" suffix will be removed before publication.

Type name:

application

Subtype name:

ohttp-keys-ext-00

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

This type identifies a key configuration as used by Oblivious HTTP and applications that use Oblivious HTTP.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

OHTTP Key Configuration Extension Registry This document establishes a registry for extension IDs. The "OHTTP Key Configuration Extensions" registry governs a 62-bit space and operates under the QUIC registration policy documented in . This new registry includes the common set of fields listed in . In addition to those common fields, all registrations in this registry MUST include a "Name" field that contains a short name or label for the extension. Permanent registrations in this registry are assigned using the Specification Required policy (), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections and of . Extensions with a value of the form 0x29 * N + 0x17 for integer values of N are reserved to exercise the requirement that unknown Extension IDs be ignored. These extensions have no semantics and can carry arbitrary values. These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. This registry initially contains the following entries: Extensions

Value	Name
0x00	EXPIRATION
0x01	NOT_BEFORE

All of these new entries use the following values for these fields:

Status:

provisional (permanent if this document is approved)

Reference:

This document

Change Controller:

IETF

Contact:

HTTPBIS Working Group ietf-http-wg@w3.org

Notes:

None

References Normative References This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. 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. 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 defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

Acknowledgments The "Not Before" and "Expiration" extensions were inspired by the "nbf" and "exp" claims in JSON Web Keys ().