Skip to main content

Oblivious HTTP

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline
Francesca Palombini
Comment (2023-03-15 for -07) Not sent
Many thanks to Sean Turner for his ART ART review:
Martin Duke
Comment (2023-01-18 for -06) Sent
# 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


### 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.
Paul Wouters
(was Discuss) Yes
Comment (2023-03-15 for -07) Sent
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.
Andrew Alston
No Objection
John Scudder
No Objection
Lars Eggert
No Objection
Comment (2023-01-16 for -06) Sent
# 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

## 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
Useless in the TXT rendering and not really that useful in the HTML rendering
either (IMO).


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, 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:


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

Murray Kucherawy
(was Discuss) No Objection
Comment (2023-01-05 for -06) Sent
Thanks to Sean Turner for doing the ARTART review.


* 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".
Roman Danyliw
No Objection
Comment (2023-01-03 for -06) Sent
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?
Zaheduzzaman Sarker
No Objection
Comment (2023-01-03 for -06) Not sent
Thanks for working on this specification. Thanks to Kyle Rose for the TSVART review.
Robert Wilton
Comment (2023-01-19 for -06) Sent
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.

Éric Vyncke
(was Discuss) Abstain
Comment (2023-03-09 for -07) Sent
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:

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 

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
Alvaro Retana Former IESG member
No Objection
No Objection (2023-01-03 for -06) Sent
The datatracker page for this document should indicate that it replaces draft-thomson-ohai-ohttp.