-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Just one point on one bit of this. TCPINC will be having some of the same discussion as they consider the pros and cons of the tcpcrypt proposal vs. some (D)TLS based ones. While its quite possible that the cases are so different that different conclusions ought be reached, I think its clear that some of the analysis will be the same. So I hope that DPRIVE and TCPINC chairs/participants try to save us all a bit of time and energy by where possible factoring out the generic parts of the argument from the DNS and TCP specific parts. And maybe subscribing to both lists would good for folks who care about the (D)TLS/generic-solution vs. protocol-specific solution topic. Cheers, S. On 12/10/14 14:23, 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. :-) > > 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 > > > > _______________________________________________ dns-privacy mailing > list [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUOoNtAAoJEC88hzaAX42icLsH/1NY/CDdvA/EhwacoFPaM0uV QUmLc8ybjUYYuoNdOIF8VxUMxuI0jRq2NB5zFxWW4mdYDRNsSL/4uGtgM7pa0py6 dCqGM+EZDRgb6/aDVoSnX38awYhxxrEgn47PBbZe2JyvZ0jI7eUXOp4DiDXWrfug T5m3wrNTBU7AUiH9DuDKP34dCf0b/6MyisBTcSUGHN+Mxc5HqPBmZM7IBjxBJVfJ AG0RNLhilHDue33+9gkqSXSetESGJlvW1+aO3PhlRSHLrY16lV65spXJuUgQEWAC zPf0P+uaRmZFQhnU+tk9SZfze5TIrOoOR3WZ5j3SRyscuJVz5Z/GYIEE1JYb7nU= =AonK -----END PGP SIGNATURE----- _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
