[Ohai] Éric Vyncke's Discuss on draft-ietf-ohai-ohttp-06: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-ohai-ohttp-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


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.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/



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


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