On Sun, 12 Oct 2014 18:53:03 +0530, Mukund Sivaraman wrote: >Hi John > >On Sat, Oct 11, 2014 at 04:25:09PM -0700, John Heidemann wrote: >> My biggest concern is that dnscurve/dnscrypt are bespoke for DNS. >> >> That's good and bad. The good is that it is very focused and has no >> "fat" for DNS. > >By bespoke, I assume you mean tailor-made for DNS. That's the only >meaning in my dictionary that fits. :-)
Yes. >DNS already uses a lot of tailor-made security parts for it like TSIG, >DNSSEC, etc. > >> But for a long-lived standard, I think one wants something that lets you >> choose the crypto protocols, and change that choice with relative ease >> in the future. (Without taking a position on ECC here, I'm saying that >> NO single protocol should be locked in.) [**] > >+1. This could be a problem for DNSCurve that hardwires to >Curve25519XSalsa20Poly1305 in case there are security issues that would >make us need to abandon it. > >On the other hand, having a choice of methods (that often include >insecure ones in protocols such as SSL) can give an implementor rope to >hang oneself. Most programmers who implement DNS are not cryptographers >and it's better that crypto is a proven-to-be-secure box. This is >something that NaCl (that DNSCurve uses) provides. > >Here is a tweet Andy Wingo made today on how much rope TLS could hand >out because it's so configurable: >https://twitter.com/andywingo/status/521232609204912129 Agreed. That was in the [**] footnote of my prior mail. To me, the necessity of future upgrade unfortunately outweighs the complexity of configurability. (And we must provide best practices to not make mistakes in our choices.) >> Given the subtlety of crypto design and implementation issues, I also >> think using an off-the-shelf design (like TLS) and with multiple, mature >> implementations has a big advantage over rolling one's one. [***] > >If TLS was suitable, then it could be considered compared to other >choices. However TLS is a protocol layered over TCP whereas much of DNS >traffic uses UDP. (and later you say) >All the protocols you've listed use TCP. The popular secure versions of >these protocols all use TLS. Much of DNS traffic is UDP. Understood. There have been discussions about the potential of TCP (and TLS) for on dnsop recently, and by several people elsewhere over the years. My views (with the help of my co-authors!) are written down in the tech report I put in my prior post, at <http://www.isi.edu/~johnh/PAPERS/Zhu14b.html>. We try hard to examine the performance concerns of TCP and TLS for DNS to both clients and servers, and provide some performance comparisons to DNScurve and DNScrypt, and look at deployment issues (appendix H). (And if one really wants UDP, then DTLS is an alternative. I don't think that helps over TLS; the argument is written out in Appendix J of the tech report.) There are a LOT of issues around deployment and performance of DNS and TCP and TLS, and a range of opinions on both (some very strong opinions :-). I encourage folks to not just discard TCP out of hand. >> Finally, dnscurve requires that the key go in the hostname of the >> server. For some, that's a downside, ranging from unpleasant to perhaps >> operationally impossible. > >Can you elaborate how this is unpleasant or operationally impossible? I think it's better for someone who runs commercial DNS services to comment on that. >> There are also a bunch of pragmatic questions: are there draft specs for >> dnscrypt and dnscurve? multiple implementations? has IETF documented >> ECC yet? These can all be fixed with work, but it's not just >> off-the-shelf. > >ECC is a general area of cryptography. I assume you mean to ask whether >the crypto used in DNSCurve (Curve25519XSalsa20Poly1305) is specified. >These are individually specified in various papers, but I don't think >any are documented at IETF. The NaCl implementation is off-the-shelf and >there is also a public domain tweetnacl.{c,h} implementation available >that programmers can use. > >There are many formats that are used by network protocols that are not >specified such as bzip2. However, +1 towards documenting them. I'm sure that nacl is really clean code, but my guess is it's not quite ready for IETF WG last call. >> But to me the core question is: is DNS really so special we >> want have design our own, new, protocol? Or can we follow what HTTP and >> SMTP and POP and IMAP do? -John _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
