Draft: draft-thomson-http-oblivious

Commentary: This is more or less implied already , but it is better to write it down . I 've stubs for some content types as well . 
 This probably covers a bunch of things , so I 'll start with a few things that might want to be discovered automatically : might want to ask the oblivious proxy resource which oblivious request resource it forwards to . might want to learn about which oblivious target resources a particular oblivious request resource is willing to forward to . might want to learn automatically about the public keys the oblivious request resource has ( along with key identifiers , see ) . might want to ask about the oblivious proxy resources that forward to a particular oblivious request resource . This is a little tricky , because clients will need to exercise discretion in selecting from this set . This also risks exposing the existence of DoS exemption agreements between the oblivious request resource server and the oblivious proxy resource server . might want to ask the oblivious target resource for an oblivious request resource ( or by extension oblivious proxy resource ) that it can use to reach that resource . If you look at this as link relations , this is two forward links , a key configuration , and two backward links . Defining link relation types for this might be a way to address this . Assuming that we also define a media type for a key configuration format , that is . 
 This seems to me to the fundamental challenge with this system , and a great many other systems . DHTs have been used to advertise resource availability , but the searched object is quite hard to blind from everyone . We could say that good is the enemy of great , only we 've been at this a while , and neither have shown up . 
 use of the word " system " is interesting here . OHTTP does not describe a system , but a protocol . The way that this protocol is deployed and used in practice , I think , defines the system . ( The same argument goes for protocols like DoH. ) So I do n't see this as a challenge to the protocol design , but rather to how one might configure and use it in practice . And that seems rightfully out of scope . 
 Document that practice a bit , then , if it is practice . I do n't view the DoH document as a resounding success , fwiw . It left many questions unanswered , to the point that we had to spin up another working group just to address them . My fundamental question remains : does ohttp contribute more positive than negative ? No use case in the document means no understanding of that . I do appreciate  and  's explanation on list . Perhaps that should be incorporated . 
 You might not find this satisfactory , but there is text in the draft about exactly the use cases that Ekr described . https://unicorn- has those two . Are you asking for more discussion of the relationship between various actors in those use cases ? 
 Martin , the example you gave was really good . The trick is to show how the players interact . 
 Discussed at IETF 113 and the WG decided that we would continue the discovery discussion in relation to other drafts . 
 We are n't really able to carry informational status codes using this form of encapsulation . Sure , we could encode an informational status as a new message , but we do n't have anywhere to include it , except as the content of a response , along with the final status code . That might not be helpful if you consider things like 100 - continue . My recommendation is to make this limitation clear and prohibit the use of 100 - continue .
Parses "enc_request" into "keyID", "enc", and "ct" (indicated
using the function "parse()" in pseudocode).  The server is then
able to find the HPKE private key, "skR", corresponding to
"keyID".  If no such key exists, the server returns an error.
Parses "enc_request" into "keyID", "enc", and "ct" (indicated
using the function "parse()" in pseudocode).  The server is then
able to find the HPKE private key, "skR", corresponding to
"keyID".  If no such key exists, the server returns an error; see
errors.
A client interacts with the oblivious proxy resource by constructing
an encapsulated request.  This encapsulated request is included as
the content of a POST request to the oblivious proxy resource.  This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(media-types), and the encapsulated request as the request content.
Clients MAY include fields that do not reveal information about the
content of the request, such as Alt-Used ALT-SVC.
The oblivious proxy resource interacts with the oblivious request
resource by constructing a request using the same restrictions as the
client request, except that the target URI is the oblivious request
resource.  The content of this request is copied from the client.
The oblivious proxy resource MUST NOT add information about the
client to this request.
When a response is received from the oblivious request resource, the
oblivious proxy resource forwards the response according to the rules
of an HTTP proxy; see Section 7.6 of HTTP.
An oblivious request resource, if it receives any response from the
oblivious target resource, sends a single 200 response containing the
encapsulated response.  Like the request from the client, this
response MUST only contain those fields necessary to carry the
encapsulated response: a 200 status code, a header field indicating
the content type, and the encapsulated response as the response
content.  As with requests, additional fields MAY be used to convey
information that does not reveal information about the encapsulated
response.
An oblivious request resource acts as a gateway for requests to the
oblivious target resource (see Section 7.6 of HTTP).  The one
exception is that any information it might forward in a response MUST
be encapsulated, unless it is responding to errors it detects before
removing encapsulation of the request; see errors.
This encapsulation does not permit progressive processing of
responses.  Though the binary HTTP response format does support the
inclusion of informational (1xx) status codes, the AEAD encapsulation
cannot be removed until the entire message is received.
In particular, the Expect header field with 100-continue (see
Section 10.1.1 of HTTP) cannot be used.  Clients MUST NOT construct a
request that includes a 100-continue expectation; the oblivious
request resource MUST generate an error if a 100-continue expectation
is received.
A server that receives an invalid message for any reason MUST
generate an HTTP response with a 4xx status code.
Errors detected by the oblivious proxy resource and errors detected
by the oblivious request resource before removing protection
(including being unable to remove encapsulation for any reason)
result in the status code being sent without protection in response
to the POST request made to that resource.
Errors detected by the oblivious request resource after successfully
removing encapsulation and errors detected by the oblivious target
resource MUST be sent in an encapsulated response.
Media types are used to identify encapsulated requests and responses.
The "message/ohttp-req" identifies an encapsulated binary HTTP
request.  This is a binary format that is defined in request.
The "message/ohttp-res" identifies an encapsulated binary HTTP
response.  This is a binary format that is defined in response.
Please update the "Media Types" registry at
https://www.iana.org/assignments/media-types [1] with the
registration information in media-types for the media types "message/
ohttp-req" and "message/ohttp-res".