A Perfect Forward Secure Extension to Oblivious HTTP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 January 2027.¶

Copyright Notice

Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Oblivious HTTP ([OHTTP]) is a protocol for forwarding encrypted HTTP messages. It does not provide Perfect Forward Secrecy (PFS). Chunked OHTTP ([CHUNKED]) expands OHTTP to be suitable for longer-lived streams, but still does not offer PFS.¶

Unfortunately, providing a streaming abstraction over OHTTP makes it an attractive tool to provide privacy. This is leading application designers to build Remote Procedure Call (RPC) systems over this bidirectional stream, without realizing the security cost of losing PFS.¶

This document proposes a solution that offers PFS to all data sent over OHTTP apart from the client's first flight. This provides privacy and security properties similar to TLS 0-RTT (see Section 2.3 of [TLS]) run over HTTP CONNECT (see Section 9.3.6 of [HTTP]) without losing the performance nor request-correlation-prevention properties of OHTTP. This mechanism is designed to be backwards compatible with unextended OHTTP.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terminology from [HPKE].¶

3. Mechanism

This mechanism relies on the generation of two more ephemeral key pairs per OHTTP request: one for the client (denoted skC, pkC) and one for the gateway (not denoted since it only exists inside of SetupBaseS).¶

The client starts by generating a second ephemeral key pair, using the same KEM it has selected for this request:¶

skC, pkC = GenerateKeyPair()

The client then adds the serialized public key SerializePublicKey(pkC) to its Binary HTTP ([BHTTP]) request headers using the "OHTTP-PFS" header. That header is a Structured Header Field Item of type Byte Sequence as defined in Section 3.3.5 of [STRUCTURED]. For example:¶

ohttp-pfs: :dGhpcyBpcyBhIHB1YmxpYyBrZXk=:

The client then encrypts the Binary HTTP request following the procedure in Section 4.3 of [OHTTP]. The gateway follows the procedure in that same section to recover the Binary HTTP request.¶

The gateway then checks the request for the presence of the "ohttp-pfs" header to determine whether this extension is in use. If it is, it uses the HPKE receiver context (rctxt) from the OHTTP request as the HPKE context (req_context) as follows:¶

req_secret = req_context.Export("OHTTP PFS Request Derivation",
                                max(Nn, Nk))
info2 = concat(encode_str("OHTTP PFS Response"),
               encode(1, 0),
               encode(1, key_id),
               encode(2, kem_id),
               encode(2, kdf_id),
               encode(2, aead_id),
               req_secret)
enc2, pctxt = SetupBaseS(pkC, info2)
ct2 = pctxt.Seal("", response)
enc_response = concat(enc2, ct2)

The client then reverses this process to extract the response.¶

This document's editor ran out of time right before the draft deadline, so this section is still a work in progress. Please check the editor's copy, they most likely have made some progress since then.¶

4. Security Considerations

TODO¶

5. IANA Considerations

6. References

Acknowledgments

Thank you to Martin Thomson and Chris Wood for asking me to write this draft.¶

Author's Address