On Thu, 09 Oct 2014 20:01:47 -0400, Warren Kumari wrote: >Hi there all, > >So, DPRIVE should be meeting in Hawaii, either as a fully fledged >working group, or like a BoF that we are planning on running like a WG >session. >... > >One agenda request -- is there anyone who is knowledgeable on DNSCurve >and can explain clearly and in baby words (suitable for the likes of >me) why this doesn't solve all our problems? Perhaps we can be the >worlds shortest WG :-)
We talk about this issue, comparing DNSCurve and DNSCrypt [*] in a section 3.2 of our tech report about T-DNS (one of the DNS-over-TLS proposals). (The tech report is at http://www.isi.edu/~johnh/PAPERS/Zhu14b/ .) My summary of what we wrote there: 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. 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.) [**] 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. [***] 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. 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. 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 [*] DNSCrypt is stub-to-recursive, and DNSCurve is recursive-to-authoritative, they're similar but different. I'll let an expert in them describe how they compare. [**] Yes choice of protocol raises complexity and risk of downgrade attacks, but one must compare that against the cost of swapping out a hard-coded choice. [***] Clearly the the recent bugs in openssl and gnutls are serious, so standard designs and common libraries is not a panacea. I think the vetting of a common design and the attention common libraries get remain hugely valuable. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
