Separating the proxy pool from the target servers about draft-pauly-adaptive-dns-privacy HOT 5 CLOSED

The end goal here I have is that the amount of Obfuscated traffic for any given resolver should be a small percentage of their resolutions. So, big resolvers (Google, Cloudflare, Fastly, Akamai, Apple, etc) would be on the hook to make sure they help the ecosystem by supporting obfuscation. Little guys, not so much.

The trick is how to get to this point. I want to ensure that the parties that benefit the most from the system (by getting control of a lot of traffic that they can shape towards them) also give back by helping ensure user privacy for other names. That's why the existing approach is a bit harsh.

You're right that right now, the requirement has two dimensions of burden:

• Every DoH server needs to support Obfuscation (they need the implementation complexity)
• Every DoH server may face an arbitrary amount of traffic burden

We can choose to mitigate this on either front. I'm wondering if we can do something to determine the scale of the resolver before we make it do obfuscation, too.

from draft-pauly-adaptive-dns-privacy.

I think that we definitely should clarify something here: we want to make sure that the incentive structure is aligned correctly, but at the same time there are very real concerns for feasible deployment.

I think that's potentially different from allowing folks to separate their operational requirements for deployment and provisioning their infrastructure, allowing flexibility around deployment is really important whatever the incentive structure.

from draft-pauly-adaptive-dns-privacy.

@mcmanus, @tfpauly, @erickinnear, is there still something to be done here? Can we close this?

from draft-pauly-adaptive-dns-privacy.

@tfpauly I think we can close this out as overcome by events.

from draft-pauly-adaptive-dns-privacy.

Agreed

from draft-pauly-adaptive-dns-privacy.