We have three proposals on the table. The question is how to score them objectively.
One approach would be to ask some party that runs a public DNS responder which of the protocols they are most likely to support. So feedback from a Verizon or a Google/8.8.8.8 would be useful. Another point to consider is whether we judge proposals as they stand now or accept modifications. I have been working on my proposal for 4 years. I have developed one code base, abstracted it, generalized and then reified the original problem in the general framework. So I don't expect my proposal to change much unless someone brings up a use case that I haven't thought about. When we get to scoring however, I know that a response to every one of the feature deficiencies I see in other proposals can be fixed. I know because I have travelled that same path before. And the reason I decided on the architecture I did was that it was the approach that required least changes to and least invention on top of existing work. The point is that if we are going to have a fair basis for comparison then either we have to disqualify proposals that don't meet the necessary feature set or we have to agree those features aren't required or we have to let people change their proposals to add the cruft necessary to meet the requirements before a comparison is made. 1) 100% connectivity There are two compliance levels that might be proposed: A) The protocol has to work in any network situation where normal DNS works OVER UDP B) The protocol has to work in any network situation where http works DPLS was originally designed to meet the stronger criteria. Private DNS only meets the second but could easily be extended to meet the first if necessary. The reason for making this change is that there are few places where DNS over UDP works but http does not. The reason that I invented what is now SXS-Connect in the first place was precisely because I can't meet that 100% connectivity requirement without some form of transport agility. It is in effect a super SRV record. Of the proposals on offer, Paul's DNS over HTTPS is the only other one that comes close to meeting this requirement. But do note that HTTPS is banned in a lot of countries. Now this probably does not make much difference if we are talking about a country like Russia or China that has permanent police state apparatus in place. But it does make a very big difference if we are talking about a situation where a government is trying an Internet crackdown to suppress evidence of government corruption ahead of an election or the like. 2) Basis for performance comparisons. If we are looking at privacy then we should be looking at the performance impact on a heavily trafficked public DNS service like 8.8.8.8, Comodo's public DNS, etc. The reason for this is that we need to be able to aggregate client requests sufficiently to avoid traffic analysis giving the game away. Large public DNS resolvers try to reduce in-band lookups to the absolute bare minimum. This is going to be even more important when DNSSEC is finally deployed because its not just about caching the DNS records and avoiding the round trip hit, its about minimizing the inband DNSSEC path math. So large public DNS resolvers will typically prefetch well trafficked DNS records on expiry of the old records. The cache hit rate for labels that exist should be well in excess of 90%. Therefore to compare like with like we have to compare round trips and public key operations for the case where we get a cache hit. Private DNS = 1 round trip, 0 public key operations, 0 server state Everything else is more. 3) DoS resilience There are several different types of DNS DoS attack. There is the attack on the resolver itself, there is the attack on an authoritative through the resolver and there is the third party attack. Private-DNS is the only proposal that considers these at all. Simply adding cryptography to the existing protocol is not a neutral change. You are going to make it impossible for ISPs to mitigate DNS attacks coming out of their networks except by blocking DPRIVE DNS. 4) Building on existing standards. I think I win this one as well. It is not possible to solve this particular problem by just slapping DTLS or TLS onto DNS. Every single one of the proposals has to add some mechanism. I arrived at my approach because it uses the least additional mechanism. It is considerably simpler than TDNS today and is a lot simpler than TDNS with the necessary extensions to address essential requirements. The problem with trying to fit TLS or DTLS into a DNS protocol is that TLS is layered on top of PKIX and the DNS. DANE does not help at all because we hit a bootstrap problem of trying to use the DNS to get records to use the DNS securely. 5) Capable of extension to stricter security requirements. Yes, I have considered cases where very high levels of concern are warranted. The SXS-Connect key exchange is a mutual authentication protocol that does not reveal the PIN inband. So if you have a 128 bit PIN code then you have a work factor of 2^128 to break either the client or service authentication. And if I goofed or got it wrong, well the only thing we would need to change is the connection protocol. But that is the easy part. I an 100% confident that myself, EKR and the security directorate will get SXS-Connect right. Thats just crypto. And its new crypto so its easy. What is hard, hard, hard is brownfield protocol design and having to work round legacy DNS or TLS gotchas. 6) Capable of being reused in other protocols. There are two ways to score reuse, one is does the protocol build on existing work. We all build on TLS as a framework with some additional stuff. I think I actually add the least but I will accept a draw on that if people want to argue. What I deliver that nobody else does is a general purpose module that can be reused for other purposes without the usual thing of chucking everything into the DNS (as per Warren's T-shirt). SXS-Connect can be applied as a way of securing a connection to a 2 factor auth service or a time service or anything else you might want. The JSON base gives you the power without any additional cost on the use for securing DNS. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
