Oblivious HTTP
draft-ietf-ohai-ohttp-10

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".

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?

Thanks for working on this specification. Thanks to Kyle Rose for the TSVART review.

The datatracker page for this document should indicate that it replaces draft-thomson-ohai-ohttp.

# 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