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. :-) 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 > 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. > 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? > 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. > 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? All the protocols you've listed use TCP. The popular secure versions of these protocols all use TLS. Much of DNS traffic is UDP. Mukund
pgplfkm_Y96Iu.pgp
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
