Christian Huitema <huit...@huitema.net>于2018年4月10日周二 上午2:44写道：
> 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. 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. > I designed another EPT asymmetric tunnel extension in 2017: https://github.com/abbypan/dns_test_ept Use EDNS padding to lighten the length limit (but recursive must forward the padding), use XOR_IP to obscure the A RR. The problem I want to address seems similar to ODNS. > > > -- Christian Huitema > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
