search

WICG / turtledove

TURTLEDOVE
https://wicg.github.io/turtledove/
Other
513 stars 216 forks source link

URL to use for inner and outer KV (v2) queries #943

Open martinthomson opened 7 months ago

martinthomson commented 7 months ago

The specification is unclear on how the k-v server will be addressed. It says that OHTTP will be used, but there is no mention of what the two URLs will be. There is only the trustedBiddingSignalsURL that the browser can use.

peiwenhu commented 7 months ago

The specification does not use OHTTP as-is with the intended setup. It uses the HPKE encryption portion of the OHTTP specification. In the typical OHTTP setup, the payload is opaque to the relay resource. In the TEE KV server case, the payload is opaque to the cloud infrastructure outside TEE.

The V2 specification could have used HPKE directly but practically OHTTP is used in other areas by Chrome, such as the K-anonymity service, so we decided to try to reuse.

So to answer the question, there is only one URL needed since the setup is simpler (the cloud infrastructure, equivalent to the relay resource, knows how to forward the request to the server inside TEE without URL).

martinthomson commented 6 months ago

The specification very clearly states that the payload is binary HTTP (RFC 9292), which requires a URL for requests. I don't know how to square that with what you are saying here. What am I missing?

peiwenhu commented 6 months ago

In Server responsibilities and Separate gateway and target and some other places it was mentioned that the gateway resource and the target resource can be operated by the same server.

That is the case here. The KV server acts as both the gateway resource and the target resource. It decapsulates requests from the client, processes it and returns an encapsulated response.

Please correct me if I'm wrong - my understanding is that the binary HTTP URL is primarily for the gateway resource to forward the requests to the target resource if they are operated as separate entities, which is not the case here.

martinthomson commented 6 months ago

Yes, the same server can (and probably should) operate both resources. But these are separate resources, with separate identities. That these are operated by the same entity doesn't change that.

peiwenhu commented 6 months ago

Pardon my ignorance - we are pretty much decapsulating the request and processing the request in the same piece of code. They don't practically have separate identities. As a result, the client only needs to know the URL to the KV server. The encapsulated request would get to the load balancer which forwards it to the KV server running inside TEE. And the KV server running inside TEE would decapsulate it, process the request and return an encapsulated response back to the client.

Perhaps we missed something or should have a better flow in which case I'm very happy to hear suggestions. Could you elaborate a bit on what the consideration behind your comment is?

martinthomson commented 6 months ago

You have established that you don't need the value, yes. That doesn't change the fact that the format requires it.

peiwenhu commented 6 months ago

Do you know if there's some convention for what value to use in this case? Can it be something fixed so the IG does not need to be aware of?

martinthomson commented 6 months ago

You're on your own, I'm afraid. This particular application was never anticipated in the Oblivious HTTP design.