On Fri, Mar 20, 2015 at 10:55 AM, Watson Ladd <watsonbl...@gmail.com> wrote: > On Fri, Mar 20, 2015 at 3:33 AM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> >> >> On 19/03/15 23:43, Zhiwei Yan wrote: >>> Hi, all, I think it's better that this draft contains some solution >>> about the client authentication to decrease/avoid the DoS attack. But >>> it's really not the focus of this draft. In order to solve this >>> problem, many other schemes can be used, such as DHCP, SAVI and DANE. >>> Anyway, this draft can make use of them to authenticate the client. >> >> I, and probably others, would fairly strongly object if the work >> of this group that is intended to enhance privacy required all >> clients to be authenticated, and hence identified, and thus give >> up privacy. >> >> There may be a place for authenticated clients in this space (e.g. >> perhaps within an Enterprise n/w) but that had better not be the >> main mitigation for potential DoS attacks. > > What's wrong with DNScrypt? Apparently people asked where the docs > are: https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES. > > The writeup isn't the best, but it should be possible to see what is > going on from this, and it seems very similar to the Wijngaards draft. > Sincerely, > Watson Ladd
Well since this is a standards forum, creating the design is 10% of the work and getting the specification written down is 80%. Getting people to agree on one approach is the other 90%. I did take a look at DNSCrypt. I don't think it is very different from mine. The main feature I add that I don't think they have is that I eliminate the overhead from multiple record queries. Which I think is necessary to make DNSSEC deployment practical or use of SRV ubiquitous. Today a DNS client typically makes separate record lookups for A and AAAA records. In discussions with the browser providers they have told me that two lookups is a hard limit for them. They are not willing to perform additional lookups for SRV, TLSA or any other records. While DNS does in theory support multiple queries, it only returns one result. This made it impossible to use multiple queries in practice and much of the legacy infrastructure is built on the assumption that there is only one query per DNS request/response. Now given that we are planning a change that is discontinuous, this is arguably something we could fix by changing the DNS protocol to add multiple responses. But that approach would require significant changes in a part of the DNS stack that is not currently affected. And it would still leave the problem of what to do when a response overruns the Ethernet MTA etc. In my experiments, it is possible to fit a 'comprehensive' DNS query consisting of A, AAAA, SRV and TLSA records in one UDP request packet and one UDP response packet smaller than the ethernet MTA for 100% of 'sensible' configurations that don't involve DNSSEC. Unless you start picking really long DNS names or obnoxiously long sets of SRV options, responses fit comfortably inside a packet. DNSSEC is a different matter if you are using RSA2048 as the signature scheme. 256 bytes per key and per signature is just too large to expect to be able to fit in one packet. But even there the signatures still fit very comfortably in 2 packets. What I am trying to do here is to maximize the acceptability of DNS Privacy to potential deployment constituencies as my top priority. * Meet all the performance constraints that the Microsoft, Mozilla and Google teams have raised with me in the past. * Maximize the potential for early adopter use by making DNS Privacy the solution to the problems of DNSSEC deployment and the use of enterprise VPN. * Minimize the complexity of the solution. By which I don't mean 'link to a huge library that is at best understood by EKR and Peter Guttman. Against this we have folk whose best argument is that their solution can be almost as good as mine if people deploy new TCP stacks. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
