ietf-wg-ohai / oblivious-http

Oblivious HTTP
Other
23 stars 12 forks source link

Section 6.2 #255

Closed martinthomson closed 1 year ago

martinthomson commented 1 year ago

Comment by @paulwouters

so delays SHOULD only be added with the consent - or at least awareness - of Clients

How would that work? How would the client consent? Or show awareness? Or become aware ?

Clients can use padding

Can't the Target Resource also not use padding in the response? But I guess they wouldn't know about being connected to obliviously or regularly, unless the Client tells the server within its encrypted payload request? Eg if a regular https server sees a certain field, it would/could know to do some padding? (one would assume ohttp relays are fairly well known on static IPs anyway, so the Client wouldn't be revealing much if it could ask the http server itself for random padding

martinthomson commented 1 year ago

There are two questions here, delays and padding. Both are areas in which the specification is not prescriptive. This is deliberate, mostly because these are areas where a single strategy would be inadvisable. Application needs vary.

How would [delays] work?

Well, in any number of ways.

A telemetry submission service (see also STAR) might provide greater privacy benefit from batching requests that are forwarded from the client to gateway. In that model, the client might tolerate arbitrary delay (see https://datatracker.ietf.org/doc/draft-wood-ohai-unreliable-ohttp/ for example). In other cases, the client still cares about a response, but it might be willing to hang around for some time (10s, 30s) for an answer.

How would the client consent? Or show awareness? Or become aware ?

How the client consents to delays can also vary. It could be part of terms of service that are negotiated when the use of the relay is arranged. That sort of arrangement might cover all these points.

If you are looking for protocol mechanisms, we've discussed explicit signaling as an extension. A client could use something like Prefer: wait=10 (see RFC 7240) to indicate that within the protocol[^1]. An explicit signal demonstrates awareness for those cases where the delay might be conditional.

[^1]: Note also that this sort of signaling might imply a need for the relay to remove that field, though perhaps all clients add it and so it doesn't reveal anything if forwarded.

Can't the Target Resource also not use padding in the response?

Yes. Section 6.3 references back to this text, but it's worth mentioning the gateway too.

There are many things that might feed into a padding strategy. Sometimes this is something the gateway will know because they are configured for a particular application and can look at the payload to determine how to best pad. Clients can probably signal (within encapsulation) what they might prefer, if that would help. Again, it's too application-specific to say much of use.

pwouters commented 1 year ago

Martin,

The comment it isn’t my comment.

Maybe there is another Pwouters in github

Kind regards

Paul

Verstuurd vanaf mijn iPad

martinthomson commented 1 year ago

My apologies. I definitely got the wrong person there.

paulwouters commented 1 year ago

thanks