Oblivious HTTP
draft-ietf-ohai-ohttp-10

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-ohai-ohttp and RFC 9458, changed IESG state to RFC Published)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ohai-ohttp-09. If any part of this review is inaccurate, please let us know.

We understand that upon approval of this document, we'll need to update existing references in the registries. Please see below.

First, upon approval of this document, for the registrations added to https://www.iana.org/assignments/media-types after this document was initially approved, we will update the references to point to the document's most recent version number.

Second, upon approval of this document, for the registrations added to https://www.iana.org/assignments/http-problem-types, we will update the references to point to the document's most recent version number.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-08-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ohai-ohttp@ietf.org, ohai-chairs@ietf.org, ohai@ietf.org, shivankaulsahib@gmail.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: EXTRA Last Call:  (Oblivious HTTP) to Proposed Standard


The IESG has received a request from the Oblivious HTTP Application
Intermediation WG (ohai) to consider the following document: - 'Oblivious
HTTP'
  as Proposed Standard

Version -08 of this draft was processed as usual by the working group and by the IESG.
While it was in the RFC Editor queue, an interoperability issue was identified. The
proposal at the time was to fix it in AUTH48, but the change was deemed too substantial
to be considered purely editorial.

Accordingly, a second Working Group Last Call was done on the proposed change, which
did not generate any objections. The OHAI working group has now posted the proposed
amended document as -09.  The proposed change, therefore, is visible in the datatracker here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-ohai-ohttp-08&url2=draft-ietf-ohai-ohttp-09&difftype=--html

This is, therefore, an IETF Last Call for a review of the proposed change only. The
IESG has placed a hold on the document in the RFC Editor queue until this Last Call
and any feedback has been resolved.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-08-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a system for forwarding encrypted HTTP
  messages.  This 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9180: Hybrid Public Key Encryption (Informational - Internet Research Task Force (IRTF))

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The draft reached broad agreement, as ascertained through both IETF session participation and mailing list/GitHub discussion. Quite a few folks raised [issues on GitHub](https://github.com/ietf-wg-ohai/oblivious-http/issues?q=is%3Aissue+is%3Aclosed). Key decisions were surfaced on the mailing list.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were a few topics that required in-depth discussion:

1. [Bad Key Configuration](https://github.com/ietf-wg-ohai/oblivious-http/issues/194): It was resolved in https://github.com/ietf-wg-ohai/oblivious-http/pull/196
2. [Asynchronous Submission Use Case](https://github.com/ietf-wg-ohai/oblivious-http/issues/179): A new draft was created to address this use-case: https://datatracker.ietf.org/doc/draft-wood-ohai-unreliable-ohttp/
3. [Signals from server to proxy or vice versa](https://github.com/ietf-wg-ohai/oblivious-http/issues/114): being handled in a separate draft, and https://github.com/ietf-wg-ohai/oblivious-http/pull/113/files has text around proxy responsibilities

Apart from GitHub, these topics were either discussed on-list or during WG session. Ultimately there was clear consensus on how to resolve these issues.

There was a late-breaking change that was raised by the authors. The chairs, authors and AD discussed this and decided to do a [quick second WGLC for the fix](https://mailarchive.ietf.org/arch/msg/ohai/8yoSxqIerxTN77N_4m773UHB20o/). There was consensus to include the fix.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are implementations in [Rust](https://github.com/martinthomson/ohttp) and [Go](https://github.com/chris-wood/ohttp-go). Apple iOS 16 includes OHTTP. Cloudflare (https://github.com/cloudflare/app-relay), Fastly (https://developer.chrome.com/en/blog/oblivious-http-for-k-anon-server-with-fastly/) and Brave have implementations as well for the server. [Chromium has shipped](https://source.chromium.org/chromium/chromium/src/+/main:net/third_party/quiche/src/quiche/oblivious_http/oblivious_http_client.h) client-side support for OHTTP.

Links to implementations have been added to 'Additional Resources' on Datatracker.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
This document interacts with HTTP WG and in general the SEC area. Participants from the HTTP and security communities were actively involved in the development of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
IANA Media Type and HTTP Problem Type registries will require update: https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-05.html#name-iana-considerations. We've [asked for early review](https://mailarchive.ietf.org/arch/msg/media-types/u3_F6Ff79amaD1AbOS_PVOfnz3I/) on the media-types mailing list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
   
This document overlaps most with ART and SEC areas, and has had review and participation from both communities.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
   
Proposed Standard, because it involves multiple parties (client, relay, gateway) implementing a commonly-understood protocol. Yes, the datatracker reflects that intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
The authors have confirmed that no IPR exists to their knowledge.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
   
Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
   
There is a downref to a CFRG document, RFC 9180 (HPKE).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
No.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
RFC 9180, as mentioned above.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
   
None.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
The IANA considerations section looks accurate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
   
N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

[Ballot comment]
Thanks for addressing my DISCUSSes.

I still think the excessive amount of links is an issue, even if they are turned from blue to black to be invisible. But that's an IESG item that should not stop this document from moving on.

[Ballot comment]
Thanks to the authors (and the OHAI WG chairs and AD for their suggestions) for the -06 as it addresses most of the points raised in my previous DISCUSS:
https://mailarchive.ietf.org/arch/msg/ohai/AroMMySrG1FTz_H9UQ5Q2KIKLKg/

I am balloting ABSTAIN as in "I oppose this document but understand that others differ and am not going to stand in the way of the others" per https://www.ietf.org/standards/process/iesg-ballots/

I.e., I understand that I am on the rough (wrt. the IESG, OHAI WG, and the IETF community), but I still have concerns about this tool that could be used outside of its applicability statement with bad intentions (like many tools):

1) reliance on the absence of collusion between the relay and the gateway

2) it could also lead to more centralisation of the Internet if the relays/gateways are operated by a handful of organisations (especially if the client has no choice but using specific ones) => a discovery mechanism is probably needed

3) open relays/gateways can open a venue to hide attacks (per design) like any open web proxies/VPN or TOR

[Ballot comment]
Abstaining because I don't want to block the publication of this document, but I also have strong concerns as to whether standardizing this type of technology is really in the long term best interests of most Internet end-users.

Specifically, my primary concern relate to whether centralizing DNS services then anonymizing DNS requests, and hence reducing the ability and opportunity for access networks to implement network level security or required regulatory content filtering is really in the best interests for all end users.

I also find the telemetry use case cited in this document to be quite weak because the solution does not (and presumably cannot) prevent the telemetry data from containing personal identifiable information.  Hence, I don't see much difference between the required trust relationship that a user must have with the client application and that of the client application's backend systems processing telemetry data.  However, in mitigation, this solution also doesn't seem to cause any harm in this case, I just don't see it really adding much value.

Regards,
Rob

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-ohai-ohttp-06

CC @evyncke

Thank you for the work put into this document.

Please find below two blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Shivan Kaul Sahib for the shepherd's detailed write-up *including* the WG consensus and the justification of the intended status.

Other thanks to Wassim Haddad, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-ohai-ohttp-06-intdir-telechat-haddad-2023-01-13/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### The relay/gateway pair vs. charter

My memory probably fails on me, but I vaguely remember that during the initial chartering of this WG, only specially modified target servers would be able to be reached with oblivious requests. It appears to me that the relay/gateway pair breaks this assumption...

The charter is clearly about "a proxy" (and not a gateway/relay combination) and furthermore the charter includes the sentence `Broad applicability is limited by multiple
factors, including the need for explicit server support of the protocol.` that appears to me as in opposition with section 2.2 about target server `This resource logically handles only regular HTTP requests and responses and so might be ignorant of the use of Oblivious HTTP to reach it.`

If I read the charter and this document correctly, then this document cannot be published as an outcome of OHAI IMHO. Happy to stand corrected.

### Security of Target Server

```
In this section, a deployment where there are three entities is considered:

A Client makes requests and receives responses
A relay operates the Oblivious Relay Resource
A server operates both the Oblivious Gateway Resource and the Target Resource
```

But, what about the other deployment scenarios that are allowed by this specification ?

I fail to read any security consideration for the target server in this case... How can it be protected from hostile clients ? At first sight, nothing is said in the document about this, so blocking requests from the gateway IP address is probably the only way, i.e., blocking all the clients. So, we are back to the old issue of blocking proxies/CGN. This seems very similar to my first DISCUSS point. So, I am probably missing something obvious.

Or, the document MUST state that gateway/target server MUST be colocated.

[Ballot comment]

## COMMENTS

### Links and acronyms

I am sympathetic with Paul's point about the amount of links. While I am usually not a big fan of acronyms, it would be nice to define acronyms for the relay and the gateway.

### Paul's DISCUSS

Paul's DISCUSS about DNS and provisioning are very valid.

### Section 6.2.2

`If a server accepts a larger volume of requests from a relay,`, it is a little unclear what the "server" is... please use Oblivious Gateway ? The same ambiguity appears in other sections (e.g., section 6.5).

### Dual-stack

Sometimes it is worth stating the obvious: all connections between intermediaries/clients/servers can be achieved with a mix of IPv4 and IPv6 ;-)

## NITS

### Section 1
s/minumum/minimum/ ?

## Notes

Martin, you know it as it is based on your work ;-)

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# Transport AD Comments for draft-ietf-ohai-ohttp-06

Thanks to Kyle Rose for the TSVART review.

Aside from nits, all I have are suggestions for extensions:

## Comments

### S6.2.1

It might be useful for the Gateway Resource to include in the headers of the Encrypted response all non-mandatory information the Oblivious Relay included in its request, so that the client need not trust the oblivious relay quite so much or know about this metadata a priori.

### S6.2.3

Perhaps another header field where the client can explicitly request delay from the Oblivious Relay, or specify a maximum delay?

## Nits

### S1

s/minumum/minimum

### S6.3

"Note that two resources that share an origin do not guarantee that requests are not forwarded without protection."

There are a lot of negatives in this sentence, so it's hard to parse. I think this means "Note that two resources might forward requests with protection even though they share an origin."

### S8.2
It would be useful to the introduce the idea that there is a one-to-one mapping of Oblivious Relay to Gateway Resource in the overview. Reading start to finish, I kept wondering how the Oblivious Relay knew where to forward the Encrypted Request.

[Ballot discuss]
# Sec AD review of draft-ietf-ohai-ohttp-06

CC @paulwouters

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions.

This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows automated tools to process items (eg to produce github issues)

# DISCUSS

### Clarification of DNS lookup

I think it would be good to add a section on how DNS works with ohttp.
Eg to clarify whether the lookup is performed by the Client (and hopefully
uses DoH or oDoH on its own) or whether it is looked up by the Oblivious
Gateway Resource. Eg is the encrypted request using an IP address or a URI.

### Media type registrations

Please address the media type registration issues raised in the secdir
review raised by Alexey Melnikov :

https://datatracker.ietf.org/doc/review-ietf-ohai-ohttp-05-secdir-lc-melnikov-2022-12-08/

Additionally, the registrations instruct IANA to use the authors email. Should
this instead point to the OHAI WG, the IESG or IETF instead?

### link fest

It seems some automated tooling was used to creating links
within the document, eg for "key configuration": 7 times in Section 3,
pointing to a few lines below in section 3.1, and even one time within
section 3.1 itself pointing recursively back to itself, and 3 more times in section 3.2, and then I stopped counting.

The same for things like "client", Oblivious Gateway Resource", etc etc
culminating in Section 5 that's more blue than black, making the blue
links, uhm, oblivious :P

### Foreknowledge

A number of items (see below comments) seem to require foreknowledge of
things. Is this currently envisioned as part of a provisioning step that
is not (yet?) standardized? Is it expected to be discoverable ? eg via DNS?
Or is an actual provisioning protocol being worked on?

[Ballot comment]
## Comments

### Dingledine2004

Using "[Dingledine2004]" as description identifier for TOR is a bit weird :P

### links without [brackets]

Links like  Oblivious Gateway Resource and clients don't have [brackets]
making it appear (to me) that these are links leaving this document, when
in fact these are links within the documents. Use [brackets] to denote that,
or use eg: Clients [Section X]  ?

### Figure 3

"See Figure 3" points to the immediately following figure 3. I think the
text can be removed to prevent the user from going to look elsewhere :P


### Section 6.1
```
The request that carries the Encapsulated Request and is sent to the Oblivious Relay Resource MUST NOT include identifying information unless the Client ensures that this information is removed by the relay.
```
How could a client "ensure" that? Couldn't this at best be "unless the Client
can trust that [...]"

### Section 6.2
```
so delays SHOULD only be added with the consent - or at least awareness - of Clients
```
How would that work? How would the client consent? Or show awareness? Or become aware ?

```
Clients can use padding
```
Can't the Target Resource also not use padding in the response? But I guess
they wouldn't know about being connected to obliviously or regularly, unless
the Client tells the server within its encrypted payload request? Eg if a
regular https server sees a certain field, it would/could know to do some
padding?  (one would assume ohttp relays are fairly well known on static IPs
anyway, so the Client wouldn't be revealing much if it could ask the http
server itself for random padding

### Section 6.3
```
Nonsecure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and Target Resources are not on the same origin.
```
Why is this not MUST NOT? And why the loosening on same origin? Wouldn't it be
best to always cause it to fail ASAP, so that the client doesn't cause plaintext
data to go between oblivious relay and target host?

### Section 6.4
```
Clients SHOULD include a Date header field in Encapsulated Requests, unless the Oblivious Gateway Resource does not use Date for anti-replay purposes.
```
How does a client know this? Preconfiguration ?

```
Oblivious Gateway Resources might need to allow for the time it takes requests to arrive from the Client, with a time window that is large enough to allow for differences in clocks.
```
Are we talking ms? sec? minutes? Any advise to implementers ?

### Section 6.5
```
Therefore, Clients MUST NOT retry a request with an adjusted date more than once.
```
How does a client know the date was adjusted by an intermediary?

### similar reference names

ODOH and ODoH seems very similar and likely to cause confusion. Rename one?

[Ballot comment]
# GEN AD review of draft-ietf-ohai-ohttp-06

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/vPN-hmYqeDx81Nwwp-G0mxqKtF8).

## Comments

### Section 2.2, paragraph 11
```
    Formats are described using notation from Section 1.3 of [QUIC].  An
    extension to that notation expresses the number of bits in a field
    using a simple mathematical function.
```
If we're going to use this description language more widely, it would
be worthwhile to factor out its definition into a separate document.

### "Appendix A.", paragraph 41
```
  Index
```
Useless in the TXT rendering and not really that useful in the HTML rendering
either (IMO).

### DOWNREFs

DOWNREF `[HPKE]` from this Proposed Standard to Informational `RFC9180`. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 4
```
-    minumum), additional data exchanged, and additional CPU cost of
-      ^
+    minimum), additional data exchanged, and additional CPU cost of
+      ^
```

#### Section 4.4, paragraph 13
```
-    reponse, error = Open(aead_key, aead_nonce, "", ct)
+    response, error = Open(aead_key, aead_nonce, "", ct)
+      +
```

#### Section 6.3, paragraph 5
```
-    Nonsecure requests - such as those with the "http" scheme as opposed
-    ^^
+    Insecure requests - such as those with the "http" scheme as opposed
+    ^
```

### URLs

These URLs in the document did not return content:

* https://iana.org/assignments/http-problem-types#date
* https://iana.org/assignments/http-problem-types
* https://iana.org/assignments/http-problem-types#ohttp-key

I guess that's because the defining document is not an RFC yet?

### Grammar/style

#### Section 4.3, paragraph 17
```
by the same KDF to extract an AEAD key key, of length Nk - the length of the
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 6.1, paragraph 2
```
e used to identify Clients, with the exception of information that a Client i
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider using "except" or "except for".

#### Section 6.5.2, paragraph 9
```
er of active configurations. A small number of configurations might need to
                            ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 10.1, paragraph 10
```
is somehow obtained by the Client. Then when a Client wishes to send an HTTP
                                    ^^^^
```
Consider adding a comma here.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Already thanked Peter E. Yee for General Area Review Team (Gen-ART) review
# GEN AD review of draft-ietf-ohai-ohttp-06

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/vPN-hmYqeDx81Nwwp-G0mxqKtF8).

## Comments

### Section 2.2, paragraph 11
```
    Formats are described using notation from Section 1.3 of [QUIC].  An
    extension to that notation expresses the number of bits in a field
    using a simple mathematical function.
```
If we're going to use this description language more widely, it would
be worthwhile to factor out its definition into a separate document.

### "Appendix A.", paragraph 41
```
  Index
```
Useless in the TXT rendering and not really that useful in the HTML rendering
either (IMO).

### DOWNREFs

DOWNREF `[HPKE]` from this Proposed Standard to Informational `RFC9180`. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 4
```
-    minumum), additional data exchanged, and additional CPU cost of
-      ^
+    minimum), additional data exchanged, and additional CPU cost of
+      ^
```

#### Section 4.4, paragraph 13
```
-    reponse, error = Open(aead_key, aead_nonce, "", ct)
+    response, error = Open(aead_key, aead_nonce, "", ct)
+      +
```

#### Section 6.3, paragraph 5
```
-    Nonsecure requests - such as those with the "http" scheme as opposed
-    ^^
+    Insecure requests - such as those with the "http" scheme as opposed
+    ^
```

### URLs

These URLs in the document did not return content:

* https://iana.org/assignments/http-problem-types#date
* https://iana.org/assignments/http-problem-types
* https://iana.org/assignments/http-problem-types#ohttp-key

I guess that's because the defining document is not an RFC yet?

### Grammar/style

#### Section 4.3, paragraph 17
```
by the same KDF to extract an AEAD key key, of length Nk - the length of the
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 6.1, paragraph 2
```
e used to identify Clients, with the exception of information that a Client i
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider using "except" or "except for".

#### Section 6.5.2, paragraph 9
```
er of active configurations. A small number of configurations might need to
                            ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 10.1, paragraph 10
```
is somehow obtained by the Client. Then when a Client wishes to send an HTTP
                                    ^^^^
```
Consider adding a comma here.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
[This document was originally on the 2023-01-05 telechat, but didn't get enough ballots. Adding it to next available telechat to give the rest of the IESG the chance to ballot. Thanks!]

[Ballot comment]
Thanks to Sean Turner for doing the ARTART review.

General:

* The downref to RFC 9180 was apparently not called out in the Last Call announcement, and that RFC isn't in the downref registry.  The IESG discussed this and concluded it should be added to the registry, so the responsible AD should make sure this gets done.

* Kudos for not allowing me to place my usual complaints about weak use of SHOULD [NOT]!

Media Type registration stuff:

* In Sections 9.1, 9.2, and 9.3, the "Optional Parameters" shouldn't be "None"; see RFC 6838, Section 5.6.  You want "N/A" here, as you have done for "Required Parameters".

* Since all three of these use Section 6 as your Security Considerations for the media types, please review Section 4.6 of RFC 6838 to make sure it conforms to what's required there.  One thing I note that's missing, for example, is a clear statement as to whether the payload of these media types is executable ("active content"; this is a MUST).

Section 4.3:

* I suggest a reference (of some kind) to RFC 9292 for the definition of "message/bhttp".

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

** Section 3.1.  What is the unit of “HPKE Symmetric Algorithms Length” – it isn’t bits, so is it bytes? Or number of “HPKE Symmetric Algorithm” instances?

** Section 6. Editorial.

  Connections between the Client, Oblivious Relay Resource, and
  Oblivious Gateway Resource

“Between” is for two things.

** Section 6.2.  Editorial

  A relay MUST NOT add information
  when forwarding requests that might be used to identify Clients, with
  the exception of information that a Client is aware of.

Recommend restating the second clause (“with the exception of information that a Client is aware of”) as it could be read to suggest that as long as the long is made aware, identifying information could be shared.

** Section 6.2.1.  Editorial.  Consider explicitly stating that the mechanism to signal to the Client the additional information that could be added by the Relay is out of scope.

** Section 6.3.

  Nonsecure requests - such as those with the "http" scheme as opposed
  to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
  and Target Resources are not on the same origin. 

Who should make that assessment?  How?

[Ballot comment]
Thanks to Sean Turner for doing the ARTART review.

General:

* Kudos for not allowing me to place my usual complaints about weak use of SHOULD [NOT]!

Media Type registration stuff:

* In Sections 9.1, 9.2, and 9.3, the "Optional Parameters" shouldn't be "None"; see RFC 6838, Section 5.6.  You want "N/A" here, as you have done for "Required Parameters".

* Since all three of these use Section 6 as your Security Considerations for the media types, please review Section 4.6 of RFC 6838 to make sure it conforms to what's required there.  One thing I note that's missing, for example, is a clear statement as to whether the payload of these media types is executable ("active content"; this is a MUST).

Section 4.3:

* I suggest a reference (of some kind) to RFC 9292 for the definition of "message/bhttp".

[Ballot discuss]
This is good stuff, and very well prepared.  I'm planning to change to "Yes" once we sort out this one procedural issue:

The downref to RFC 9180 was apparently not called out in the Last Call announcement, and that RFC isn't in the downref registry.  Placing a DISCUSS so the IESG can, well, discuss this and figure out whether it's something that needs further action.

[Ballot comment]
[Incomplete ballot]

Thanks to Sean Turner for doing the ARTART review.

General:

* Kudos for not allowing me to place my usual complaints about weak use of SHOULD [NOT]!

Media Type registration stuff:

* In Sections 9.1, 9.2, and 9.3, the "Optional Parameters" shouldn't be "None"; see RFC 6838, Section 5.6.  You want "N/A" here, as you have done for "Required Parameters".

* Since all three of these use Section 6 as your Security Considerations for the media types, please review Section 4.6 of RFC 6838 to make sure it conforms to what's required there.  One thing I note that's missing, for example, is a clear statement as to whether the payload of these media types is executable ("active content"; this is a MUST).

Section 4.3:

* I suggest a reference (of some kind) to RFC 9292 for the definition of "message/bhttp".

[Ballot comment]
[Incomplete ballot]

Media Type registration stuff:

In Sections 9.1, 9.2, and 9.3, the "Optional Parameters" shouldn't be "None"; see RFC 6838, Section 5.6.  You want "N/A" here, as you have done for "Required Parameters".

Since all three of these use Section 6 as your Security Considerations for the media types, please review Section 4.6 of RFC 6838 to make sure it conforms to what's required there.  One thing I note that's missing, for example, is a clear statement as to whether the payload of these media types is executable ("active content"; this is a MUST).

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ohai-ohttp-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are three actions which we must complete.

In addition, we understand that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: Problem Details for HTTP APIs
[draft-ietf-httpapi-rfc7807bis-04].

First, in the application space of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new registration will be made as follows:

Name: ohttp-keys
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the message space of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

two new registrations will be made as follows:

Name: ohttp-req
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: ohttp-res
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> Would it be acceptable to list the IETF as the change controller for the media type registrations instead of the IESG? There has been a preference for doing so, as described in the expired document at https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00, but it hasn\u2019t been recorded in a permanent document yet.

Third, in the HTTP Problem Types registry that would be created upon approval of Problem Details for HTTP APIs [draft-ietf-httpapi-rfc7807bis-04], two new problem types would be registered as follows:

Type URI: https://iana.org/assignments/http-problem-types#date
Title: Date Not Acceptable
Recommended HTTP Status Code: 400
Reference: [ RFC-to-be; Section 6.5.2 ]

Type URI: https://iana.org/assignments/http-problem-types#ohttp-key
Title: Oblivious HTTP key configuration not acceptable
Recommended HTTP Status Code: 400
Reference: [ RFC-to-be; Section 5.3 ]

Please note that while we can't link to specific registrations when the above URIs are entered into a browser, it will redirect to the registry page.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-12-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ohai-ohttp@ietf.org, francesca.palombini@ericsson.com, ohai-chairs@ietf.org, ohai@ietf.org, shivankaulsahib@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Oblivious HTTP) to Proposed Standard


The IESG has received a request from the Oblivious HTTP Application
Intermediation WG (ohai) to consider the following document: - 'Oblivious
HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-12-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a system for forwarding encrypted HTTP
  messages.  This 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The draft reached broad agreement, as ascertained through both IETF session participation and mailing list/GitHub discussion. Quite a few folks raised [issues on GitHub](https://github.com/ietf-wg-ohai/oblivious-http/issues?q=is%3Aissue+is%3Aclosed). Key decisions were surfaced on the mailing list.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were a few topics that required in-depth discussion:

1. [Bad Key Configuration](https://github.com/ietf-wg-ohai/oblivious-http/issues/194): It was resolved in https://github.com/ietf-wg-ohai/oblivious-http/pull/196
2. [Asynchronous Submission Use Case](https://github.com/ietf-wg-ohai/oblivious-http/issues/179): A new draft was created to address this use-case: https://datatracker.ietf.org/doc/draft-wood-ohai-unreliable-ohttp/
3. [Signals from server to proxy or vice versa](https://github.com/ietf-wg-ohai/oblivious-http/issues/114): being handled in a separate draft, and https://github.com/ietf-wg-ohai/oblivious-http/pull/113/files has text around proxy responsibilities

Apart from GitHub, these topics were either discussed on-list or during WG session. Ultimately there was clear consensus on how to resolve these issues.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are implementations in [Rust](https://github.com/martinthomson/ohttp) and [Go](https://github.com/chris-wood/ohttp-go). Apple iOS 16 includes OHTTP. Cloudflare (https://github.com/cloudflare/app-relay) and Brave have implementations as well.

Links to implementations have been added to 'Additional Resources' on Datatracker.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
This document interacts with HTTP WG and in general the SEC area. Participants from the HTTP and security communities were actively involved in the development of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
IANA Media Type and HTTP Problem Type registries will require update: https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-05.html#name-iana-considerations. We've [asked for early review](https://mailarchive.ietf.org/arch/msg/media-types/u3_F6Ff79amaD1AbOS_PVOfnz3I/) on the media-types mailing list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
   
This document overlaps most with ART and SEC areas, and has had review and participation from both communities.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
   
Proposed Standard, because it involves multiple parties (client, relay, gateway) implementing a commonly-understood protocol. Yes, the datatracker reflects that intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
The authors have confirmed that no IPR exists to their knowledge.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
   
Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
   
There is a downref to a CFRG document, RFC 9180 (HPKE).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
No.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
RFC 9180, as mentioned above.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
   
None.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
The IANA considerations section looks accurate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
   
N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The draft reached broad agreement, as ascertained through both IETF session participation and mailing list/GitHub discussion. Quite a few folks raised [issues on GitHub](https://github.com/ietf-wg-ohai/oblivious-http/issues?q=is%3Aissue+is%3Aclosed). Key decisions were surfaced on the mailing list.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were a few topics that required in-depth discussion:

1. [Bad Key Configuration](https://github.com/ietf-wg-ohai/oblivious-http/issues/194): It was resolved in https://github.com/ietf-wg-ohai/oblivious-http/pull/196
2. [Asynchronous Submission Use Case](https://github.com/ietf-wg-ohai/oblivious-http/issues/179): A new draft was created to address this use-case: https://datatracker.ietf.org/doc/draft-wood-ohai-unreliable-ohttp/
3. [Signals from server to proxy or vice versa](https://github.com/ietf-wg-ohai/oblivious-http/issues/114): being handled in a separate draft, and https://github.com/ietf-wg-ohai/oblivious-http/pull/113/files has text around proxy responsibilities

Apart from GitHub, these topics were either discussed on-list or during WG session. Ultimately there was clear consensus on how to resolve these issues.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are implementations in [Rust](https://github.com/martinthomson/ohttp) and [Go](https://github.com/chris-wood/ohttp-go). Apple iOS 16 includes OHTTP. Cloudflare (https://github.com/cloudflare/app-relay) and Brave have implementations as well.

Links to implementations have been added to 'Additional Resources' on Datatracker.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
 
This document interacts with HTTP WG and in general the SEC area. Participants from the HTTP and security communities were actively involved in the development of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
IANA Media Type and HTTP Problem Type registries will require update: https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-05.html#name-iana-considerations. We've [asked for early review](https://mailarchive.ietf.org/arch/msg/media-types/u3_F6Ff79amaD1AbOS_PVOfnz3I/) on the media-types mailing list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
 
N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
 
Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
   
This document overlaps most with ART and SEC areas, and has had review and participation from both communities.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
   
Proposed Standard, because it involves multiple parties (client, relay, gateway) implementing a commonly-understood protocol. Yes, the datatracker reflects that intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
The authors have confirmed that no IPR exists to their knowledge.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
   
Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
   
There is a downref to a CFRG document, RFC 9180 (HPKE).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
No.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
RFC 9180, as mentioned above.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
   
None.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
The IANA considerations section looks accurate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
   
N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Changed document external resources from:

github_org https://github.com/ietf-wg-ohai
github_repo https://github.com/ietf-wg-ohai/oblivious-http

to:

github_org https://github.com/ietf-wg-ohai
github_repo https://github.com/ietf-wg-ohai/oblivious-http
related_implementations https://github.com/chris-wood/ohttp-go (Go implementation)
related_implementations https://github.com/cloudflare/app-relay (OHTTP relay as a worker)
related_implementations https://github.com/martinthomson/ohttp (Rust implementation)