OK, I implemented this using a very simple systemd-system-proxyd config, which took less time than writing this e-mail. You can try it at 104.196.109.96:853, with a TLS authentication name of "dns.quad9.net". If you run DNS over TLS to that machine, you can verify that your queries are going to Quad9, but they'll see my machine's IP, not yours.
Some other thoughts: If deployed at scale, this approach would create some interesting questions around rate limiting and DDOS defense. Oblivious DNS has an advantage here.. This could be compatible with "name only" DPRIVE clients (like Android), if the backend domain owner creates a subdomain that resolves to the forwarder's IP and is covered by the backend cert. This requires a lot of trust in the backend domain owner, who could change the subdomain to their own IP at any time. Session Tickets and ClientHello Fingerprinting seem important. A pervasive surveillance adversary can defeat these approaches pretty easily. Defending against that would probably require another layer of encryption, as well as agreed-upon padding discipline and a delay strategy. On Sun, Jul 15, 2018 at 10:20 AM Nick Feamster <[email protected]> wrote: > > > > On Jul 14, 2018, at 9:43 PM, Ben Schwartz <bemasc= > [email protected]> wrote: > > > > For the record, I'm proposing something much _weaker_ than Tor: a TCP > packet forwarder relaying a DNS-over-TLS stream. It seems to me that this > matches Oblvious DNS's security components: a non-transforming element (TCP > forwarder, recursive resolver) to obscure the client IP, and then a > cryptographic element (DPRIVE resolver, Oblivious DNS resolver) to decrypt > the query without knowledge of the true source. > > > > Yes, absolutely, this is a lot closer to the guarantees we’re going for. > You’ve captured the spirit and the design goals. :-) > > > I would be interested in understanding why the authors don't find this > sufficient, especially since (unlike Tor) it's compatible with deployed > DNS-over-TLS clients like Stubby. > > > > (I suspect they might object to the multi-query session semantics, or > the wide variety of TLS ClientHellos, but I don't actually know.) > > A reasonable idea, definitely. > > It strikes me that there will definitely be more overhead unless you’re > pipelining queries on the connection, of course. We haven’t tried this, but > I also wonder what happens to the TLS handshake if the IP address is > rewritten through the forwarder. > > It does seem like a reasonable design alternative to consider and evaluate > against. Are you here at the Hackathon today? We can/should chat a little > bit. I’m sitting near the front. > > -Nick > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
