Hi, what you have done on DNS privacy protection sounds attractive and interesting. What we concern usually is the induced DNS resolution delay, and is it convenient for you to reveal some numbers about the extra delay caused by your so-called original Private-DNS protocol compared with normal DNS resolution delay?
Guangqing Deng CNNIC From: Phillip Hallam-Baker Date: 2015-02-04 02:04 To: Warren Kumari CC: [email protected] Subject: Re: [dns-privacy] Agenda for DPRIVE in Dallas. On Tue, Feb 3, 2015 at 11:01 AM, Warren Kumari <[email protected]> wrote: Hi all, The Dallas meeting is approaching, and we'd like to start getting the agenda organized. Please send us requests for time, etc. We have not made nearly as much progress since Hawaii as we'd hoped for / expected - sorry. Tim and I hope to chat early next week to discuss how to move things forward... The key for me is are we going to design a protocol that is designed to be part of the Internet core and replace legacy DNS for the client-resolver loop or are we just going to produce a protocol that makes privacy possible when needed. My criteria for the two approaches are very different. If we are doing core architecture then what matters is the absolute size of the library needed to implement the DNS-Privacy protocol. If on the other hand we are just trying to provide additional privacy for Web users then what matters is the delta between the standard Web stack and the new. Since writing my original Private-DNS protocol, I have made some improvements that I should be able to share in draft form soon. In particular, progress in the ECC debate in CFRG means I am no longer so worried about putting public key crypto in the client-resolver loop. But I still want to be able to insulate the hosts performing DNS lookup from arbitrary Internet users attempting to connect to them. So I still want to separate the process of validating and credentialing an account at a DNS resolver and making query transactions. I have also made some progress on the problem of using private-DNS in situations where strong privacy guarantees are required but I am not yet ready to disclose these. What I can say now is that if people want to have maximum flexibility in making DNS clients effectively anonymous to resolvers, then the preferred approach is to decouple the application of encryption and authentication to DNS packets from the key negotiation interaction. For obvious reasons, there is a limit to the extent to which we can produce privacy protection protocols in a public process such as IETF that are going to be effective in environments where the network is controlled by a hostile government. So rather tip our hand to the dictators, I would prefer to produce a protocol with one component that can be swapped out to make such changes and clearly mark it as such.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
