On Mon, Apr 9, 2018 at 2:43 PM, Christian Huitema <huit...@huitema.net> wrote: > On 4/9/2018 11:00 AM, Warren Kumari wrote: > > On Mon, Apr 9, 2018 at 1:53 PM Christian Huitema <huit...@huitema.net> > wrote: >> >> At first sight, it seems that this moves the logging hole from the DNS >> recursive to the ODNS recursive, and that's a meh. >> >> Also, instead of using a complicated tunneling through the recursive >> resolver via name obfuscation, why not establish a secure connection to the >> ODNS server in the first place? > > > The ODNS server doesn't know the client IP (it gets occluded by the > rescursive server), and the rescursive doesn't know the question. This is > kinda somewhat similar to the Tor model. > > This is a fairly common question - I think that the ODNS documents / people > should clarify this better.. > > > They should really clarify the problem that they are addressing.
Agreed -- I'm not supporting (or trashing!) ODNS, but I've heard the above question basically every time I've heard ODNS described; seeing as this is the main differentiator / benefit of ODNS, I think that it would be good it it were clear(er). W > As Shumon > said, if the goal is to hide the source IP address from the recursive > resolver, then it seems that "DNS over onion routing" would be easier to > engineer and deploy than "oblivious DNS". > > They should also clarify the use of symmetric key encryption. Is the > symmetric key specific to a client-server pair, or is shared by the server > with a large group of clients? If the key is specific to a client, then it > identifies the client even if the IP address is hidden. If the key is widely > shared instead, then it takes only one bad client for the key to leak, and > the traffic logs at the recursive DNS can be de-obfuscated. > > From an engineering point of view, I am concerned with applications of > encryption to small size objects like name part or IP addresses. Modern > symmetric algorithms operate on 128 bit blocks, with mainline AEAD > encryption adding 16 bytes of overhead to the object. That's bad enough, but > asymmetric algorithms are even worse. Even if you use Elliptic Curve crypto, > the smallest practical key is 256 bits, or 32 octets. The overhead will make > that impractical. If we happen to need longer keys it will just not fit in > the 63 octets of a domain name part, even if we found a way to not require > Base64 encoding. I am much more confident that we can solve the engineering > issues if we develop an encrypted transport with onion routing. > > -- Christian Huitema > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
