The focus on the client-resolver link is the right one precisely because the resolver-server link raises very different privacy issues. Yes, the scheme I proposed, PRIVATE-DNS can be applied to either the client-resolver link or the resolver-server link. But the privacy concerns being addressed are completely different and so are the DoS by crypto issues and much else.
Query minimization looks to me to be something where the security part takes five minutes 'don't send information that isn't necessary' and the DNS part takes five meetings. It is all going to be considering DNS corner cases and so let DNSOPs have it. Doing the crypto for PRIVATE-DNS is easy. The hard part is considering the corner cases. And the sets of corner cases are very different. For the resolver-server link the server does not have a long term relationship with the client by default. So DoS by crypto is a huge issue. We can use a Kerberos approach to amortize the cost of public key crypto across multiple connections. But the leverage might be rather disappointing. For the client-resolver link the first step to sanity is that the client picks one DNS service and sticks with it. No more casual-DNS. Once that decision is taken we can amortize the cost of public key crypto over the lifetime of the client-resolver relationship. It makes perfect sense to key once in a lifetime. So DoS by crypto is a completely avoidable problem. The other big corner case for the client-resolver link is obnoxious middleboxes. My view is that its time to just give up on port 53 and pick a new one. That works well enough for 97% of network locations. So do that when you can and fall back to port 80 when you can't. The charter seems to be less enthusiastic about authentication than I would want. I see no point in crypto without authentication. But again the game is very different. For the resolver-server link the game to play is probably DNSSEC while for the client-resolver link it almost certainly isn't DNSSEC unless you are doing DANE like records. Getting a DNSSEC A record is like getting an armored truck making silver bullion deliveries to your park bench - after you have switched to the gold standard. What is critical is that the resolver has to be able to authenticate its response to the client so that it can't be spoofed. Without authentication on that link it is possible to compromise privacy through an integrity attack. So net-net, I can make a case for a DNSCurve 'make public key crypto fast' approach being an acceptable answer at the resolver-server link. But I think it is clearly not the answer for the client-resolver link where a two step process is much better. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
