Man in the middle for obfuscated DOH

[BrianGithubber]

I think we need to update the security considerations.

In obfuscated DOH you are explicitly not trusting either name server, s.t. no one server can know both the client IP and the name the client wants resolved.
But if you don’t trust the Obfuscation Target, it can still get the client IP indirectly. The Target can just give out some man-in-the-middle IP address to the client for the given name. Then when the client connects to that address, the man-in-the-middle server just forwards the connection to the real server. The man-in-the-middle server doesn’t actually terminate the client HTTPS, but it does have enough info to (reasonably) reliably associate client IP to name it resolved. This works much better with V6, since you’d need 1 man-in-the-middle IP per name.

[tfpauly]

Yes, you’re definitely correct that this is a danger. I think there are a few possible mitigations to this, which we should note in the privacy/security considerations (an issue would be appreciated!):

• A DNSSEC-signed answer would make this much harder, if not impossible to spoof. So, we can hope that in time an uptick in DNSSEC would help cover this gap
• The client can choose to try some percentage of name resolutions over two different combinations of targets and proxies. Of course, these can differ naturally, but we could imagine some heuristics for identifying an attack, at which point the server can be blacklisted.
• The client could also try requesting the name using the same target over a different proxy (to look like a different client) after some time to see if the answer is suspicious
• We’ve discussed an overall auditing process to try to revoke the usage of servers that do such attacks.