A Perfect Forward Secure Extension to Oblivious HTTP
draft-schinazi-httpbis-ohttp-pfs-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David Schinazi | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schinazi-httpbis-ohttp-pfs-00
HTTP D. Schinazi
Internet-Draft Google LLC
Intended status: Standards Track 6 July 2026
Expires: 7 January 2027
A Perfect Forward Secure Extension to Oblivious HTTP
draft-schinazi-httpbis-ohttp-pfs-00
Abstract
Oblivious HTTP (OHTTP) is a protocol for forwarding encrypted HTTP
messages. It does not provide Perfect Forward Secrecy (PFS).
Chunked OHTTP expands OHTTP to be suitable for longer-lived streams,
but still does not offer PFS. Combined, this is leading sensitive
traffic to de deployed at scale without PFS. This document proposes
a solution.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://DavidSchinazi.github.io/draft-schinazi-httpbis-ohttp-pfs/
draft-schinazi-httpbis-ohttp-pfs.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
schinazi-httpbis-ohttp-pfs/.
Discussion of this document takes place on the HTTP Working Group
mailing list (mailto:ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/. Working Group
information can be found at https://httpwg.org/.
Source for this draft and an issue tracker can be found at
https://github.com/DavidSchinazi/draft-schinazi-httpbis-ohttp-pfs.
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/.
Schinazi Expires 7 January 2027 [Page 1]
Internet-Draft Perfect Forward Secure OHTTP July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5.1. OHTTP-PFS HTTP Header Field . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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.
Schinazi Expires 7 January 2027 [Page 2]
Internet-Draft Perfect Forward Secure OHTTP July 2026
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:
Schinazi Expires 7 January 2027 [Page 3]
Internet-Draft Perfect Forward Secure OHTTP July 2026
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 (https://davidschinazi.github.io/draft-schinazi-
httpbis-ohttp-pfs/draft-schinazi-httpbis-ohttp-pfs.html), they most
likely have made some progress since then.
4. Security Considerations
TODO
5. IANA Considerations
5.1. OHTTP-PFS HTTP Header Field
TODO
6. References
6.1. Normative References
[BHTTP] Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022,
<https://www.rfc-editor.org/rfc/rfc9292>.
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/rfc/rfc9458>.
Schinazi Expires 7 January 2027 [Page 4]
Internet-Draft Perfect Forward Secure OHTTP July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[STRUCTURED]
Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/rfc/rfc9651>.
6.2. Informative References
[CHUNKED] Pauly, T. and M. Thomson, "Chunked Oblivious HTTP
Messages", Work in Progress, Internet-Draft, draft-ietf-
ohai-chunked-ohttp-08, 18 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ohai-
chunked-ohttp-08>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Acknowledgments
Thank you to Martin Thomson and Chris Wood for asking
(https://mailarchive.ietf.org/arch/msg/ohai/
Vrh25BxK4wmIDJxeRYrYj6U1-g0/) me
(https://mailarchive.ietf.org/arch/msg/ohai/
AAWH6Cp3OmxwEuzoxehYFh1O4ck/) to write this draft.
Author's Address
David Schinazi
Google LLC
Email: dschinazi.ietf@gmail.com
Schinazi Expires 7 January 2027 [Page 5]