search

chris-wood / draft-unreliable-ohttp

Other
2 stars 2 forks source link

Conditional gateway behaviour can leak encapsulated information #3

Open rillian opened 2 years ago

rillian commented 2 years ago

The role of the Gateway Resource in reliable OHTTP is to decrypt the Encapsulated Request and forward it to the Target Resource. We should probably say something about the privacy risk of using the decrypted contents of the Encapsulated request in any conditional behaviour, since this leaks information which should be private between the Gateway and Client to the Relay, and possibly to external traffic observers.

An example of such conditional behaviour would be looking at the Host or other header fields in the Encapsulated Request when deciding whether to enforce unreliable OHTTP by returning 406 Not Acceptable, or deciding whether to return an Encapsulated Response when the Accept header received from the Relay allows this choice.

Probably goes in the Security Considerations and/or Gateway Considerations sections.

Note that while it's possible for the Gateway to decide whether to require an unreliable OHTTP request based on information in the Encapsulated Request, doing so leaks information about the contents to the Relay. Implementations must take this into account in deployment so they do not violate the privacy properties of the OHTTP channel.

chris-wood commented 2 years ago

I don't think we should allow or recommend this type of behavior, although we can't enforce what happens if someone violates the rule. I think we should just document what can happen if this conditional behavior is implemented. Perhaps we could extend the differential treatment section in the main OHTTP spec to include this discussion?

rillian commented 2 years ago

Sounds reasonable, although I think the OHTTP draft is at the end of last call. It does already have a number of warnings about leaking encapsulated information, as you mention. I think we should build on that in this draft by just mentioning the issue as a continuation of those warnings.

Picking a delivery policy based on Host or another header is something I can imagine a new implementation doing, so I wanted to say something against it here where the enabling logic originates.

chris-wood commented 2 years ago

Sounds reasonable, although I think the OHTTP draft is at the end of last call. It does already have a number of warnings about leaking encapsulated information, as you mention. I think we should build on that in this draft by just mentioning the issue as a continuation of those warnings.

Right, I meant to extend the discussion here in this draft, not to update the main spec.

Picking a delivery policy based on Host or another header is something I can imagine a new implementation doing, so I wanted to say something against it here where the enabling logic originates.

Yep, that makes sense 👍