Use Proxy-Authorization as an example header from Client to Proxy #119
Conversation
draft-ietf-ohai-ohttp.md
Outdated
| about the content of the request, such as Alt-Used {{?ALT-SVC=RFC7838}}, or | ||
| information that it trusts the oblivious proxy resource to remove, such as | ||
| about the content of the request, such as Proxy-Authorization {{?SEMANTICS=RFC9110}}, | ||
| or information that it trusts the oblivious proxy resource to remove, such as |
There was a problem hiding this comment.
Hmm, Alt-Used was good in that it didn't really convey much information. But when you go to Proxy-Authorization (which I agree is better), you need to make a stronger claim. It's one we should have had before anyway.
That is, the information needs to be stuff the client wants the proxy to know AND stuff that the client knows/trusts the proxy will remove. Because we are framing this as "forwarding", we need to be more explicit about that bit.
There was a problem hiding this comment.
Possibly OT but to be really pedantic, doesn't "content-type" reveal information about the content? Is content-length allowed?
Can we be clearer what information is deemed revealing? Perhaps the intention is to not reveal information that is strictly part of the encapsulated request, rather than metadata about the encapsulated request.
There was a problem hiding this comment.
Possibly OT but to be really pedantic, doesn't "content-type" reveal information about the content? Is content-length allowed?
The content-type header in the message to the proxy would be "message/ohttp-req", which doesn't reveal anything.
Can we be clearer what information is deemed revealing? Perhaps the intention is to not reveal information that is strictly part of the encapsulated request, rather than metadata about the encapsulated request.
I think it's neither. To me, "revealing" in this context means information that is not independent of the encapsulated request.
There was a problem hiding this comment.
That is, the information needs to be stuff the client wants the proxy to know AND stuff that the client knows/trusts the proxy will remove. Because we are framing this as "forwarding", we need to be more explicit about that bit.
Good catch -- I clarified this in the latest version.
There was a problem hiding this comment.
I'm being pedantic based on the HTTP definition of content https://www.rfc-editor.org/rfc/rfc9110.html#section-6.4
I'd expect most fields in the request to the proxy would be metadata about the encapsulating request. For instance, letting the proxy know the content-length helps it know when a POST request is complete. That doesn't seem independent of the content, is it allowed?
What information is not independent of the content? The stuff inside the encapsulating request? Why would a client ever extract that to send to the proxy?
There was a problem hiding this comment.
Content-Length is exceptional here. The general principle is this: the information attached must not leak anything about the plaintext request beyond its length.
There was a problem hiding this comment.
Understood thanks. But I'm still confused, sorry. Would something like Content-Digest fall into the same bracket as Content-Length? The calculation of the Digest would be trivial for the proxy to do if it can opaquely read the bytes of the encapsulating request. Which makes me wonder, is the requirement really about avoiding the addition of headers that are not available to the proxy unless there is introspection of the encapsulated request?
Like I said above, HTTP doesn't typically use HTTP to expose information from within the message content. If there are registered headers that by definition would violate the principle you linked, could we include them as an illustration?
There was a problem hiding this comment.
Understood thanks. But I'm still confused, sorry. Would something like Content-Digest fall into the same bracket as Content-Length? The calculation of the Digest would be trivial for the proxy to do if it can opaquely read the bytes of the encapsulating request.
No, since Content-Digest is computed over the encapsulated request, not the plaintext request.
Which makes me wonder, is the requirement really about avoiding the addition of headers that are not available to the proxy unless there is introspection of the encapsulated request?
I think it's more that the headers shouldn't reveal anything to the proxy that the proxy couldn't learn on its own through introspection of the request, which is why Content-Length is exceptional.
One could probably argue that independence is not sufficient here, since there are headers one might put on the inner request (like Sec-CH-Mobile or any other Client Hint) that doesn't belong in the outer request, but it doesn't make any sense for clients to reveal these to the proxy. In any case, I'm happy if folks want to offer up alternative phrasings here.
cc @LPardue
Closes #118