chris-wood
commented
12 months ago From the call: address this via deployment specific considerations, stating that use cases which may need to hide the IP from mirrors should proxy requests. Also note the potential chicken-and-egg problem that can arise if one is using OHTTP to run K-Check for OHTTP!
In K-Check, the mirrors appear to learn the client IPs. (There is no requirement to access the mirrors only via a trusted transport proxy.) Even if the colluding parties aren't able to correlate the individual client IPs to specific requests (e.g. via a timing attack as in #14), a malicious mirror could reveal the entire IP pool to the target. The target may be able to join configuration use with externally available information about the client IPs to deanonymize requests.
For example, consider a web search use case over OHTTP, with a client IP pool of 1,000 users. If a search query arrives for a topic that is only of interest to 10% of users, in a language spoken by 10% of users, from a user-agent used by 10% of users, then the search provider might be able to use an external user profiling database to identify one client IP in the pool that is likely to be the source of that request.
A possible mitigation would be to avoid using more than X% of the total pool of mirrors and keep that subset stable over time. This reduces the likelihood that any single mirror can leak more than a fraction of the total client IP pool. If one of the mirrors is colluding, the target only learns X% of the client IP pool. This means that even if one client IP has a profile that is highly consistent with a particular request, there is also a significant possibility that the request came from some other, unknown client IP.