The proposal is a reasonable approach and not overly complex. The question that concerns me though is how the client authenticates the resolver. Without authentication, encryption is useless because you could be having the conversation with Mallet.
Using DNSSEC for that is problematic since the credentials in DNSSEC are designed to be ephemeral. Even PKIX certs, limited to 60 months becomes a real problem. And both approaches have circular dependency issues. Another concern that I have is that the protocol has to protect resolver hosts from a Denial of Service attack. That means that the hosts cannot perform any function that provides an attacker with 'leverage' unless the request passes authentication first. So the first thing I think is necessary in any proposal is to separate out the problem of how the client-resolution service context is established from the mechanism used to enhance the DNS packets. The second part of the proposal is very straightforward. A simple framing scheme using the tools already present in the TLS toolkit can be devised and implemented in few hours. Supporting parallel UDP and TCP or even UDP and HTTPS schemes is not a major overhead. The hard part is how you decide to set up the initial relationship between the client and the resolver and how long you want it to last.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
