Hi Warren On Thu, Oct 09, 2014 at 08:01:47PM -0400, Warren Kumari wrote: > 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 :-)
This is a modified copy of what I sent to an internal list at my .org. If anyone thinks any of the following is incorrect, please feel free to correct me. The DNSCurve draft is here: http://tools.ietf.org/html/draft-dempsky-dnscurve-01 You may also want to go through the NaCl library that provides this crypto box interface for programs to use. tweetnacl.{c,h} is a simpler version of it that programmers can easily use. Pros: * It seems simple to add support in implementations (programmer), deploy and maintain (admin) * Offers authenticated and secure DNS message transmission between caching resolver and auth server * Can work over UDP and TCP. No "secure channel establishment". E.g., between a caching resolver and a newly found auth server, you can have 1 UDP datagram for query, 1 UDP datagram for response, no additional roundtrips. Having UDP support is a win for many reasons. * No additional state maintenance on servers * Client sends its public key (and nonce) as part of query and can change it regularly. I'm not sure if it qualifies as "forward security". * I haven't seen anything that'd make it incompatible with existing DNS parts like DNSSEC, TSIG, UPDATE, [IA]XFR, etc. * pros compared to DNSSEC related to authenticated data (apart from security): + There'd be no need to use DNSSEC when DNSCurve is used as it also authenticates data (keys are associated with the zone). For example, with such a system a stub might query a cache with AD=1 and DO=0 (RFC 6840) and receive what it can consider authentic data. + Though online, it _may_ arguably be faster than DNSSEC due to NSEC3 hash computations and associated lookups for the latter. (Said in a very feeble voice ;) I haven't tested it.) + Zone enumeration situation is identical to DNSSEC-less DNS, whereas there are attacks on NSEC3 + No complicated key rollover dance (compared to DNSSEC, where there's a high chance of mistakes if done manually) + No zone bloat + No frequent server-side rollovers required Cons: * How it "extends" DNS fields seems a bit messy to me, esp. the TXT case. Surely there are better ways to do it. * DNSCurve hardwires the security method it uses to 1 box: Curve25519XSalsa20Poly1305 (vs. a protocol like TLS that offers everything under the sun). This is both a disadvantage (if it is broken) and an advantage (not easy to shoot yourself in the foot by picking weak methods). But this can be extended by adding fields that specify the method used. * DNSCurve is under-specified, but this can be improved * UDP amplification needs to be checked * Not all firewalls may like it as they are bad at DNS UDP datagrams, esp. if raw streamlined format is sent to port 53 and also the query datagram sizes. * cons compared to DNSSEC related to AD: + Keys have to live on the nameservers + The entity supplying the DNS data cannot use another untrusted party's nameserver to serve it, as they cannot give them a pre-signed zone. Other bits: * It's not clear from the draft what the contents of the crypto box are, whether it's the complete DNS message, UDP packet?! or something else. The crypto box has an overhead of 16 octets. So for message of size M octets, the crypto box takes 16 + M octets. * The draft doesn't say clearly if the streamlined format is sent directly as UDP payload to port 53. In streamlined format, query overhead is 68 octets + sizeof (DNS message). Reply UDP payload is 48 octets + sizeof (DNS message). * Public keys are distributed in RDATA of NS records (embedded in the NSDNAME) in the parent zone, so there's similar hierarchical key distribution to DNSSEC. For ".", it'd need a trust anchor. * To avoid roundtrips, a recursor can "guess" that nameservers support DNSCurve by looking at the "uz5" prefix-named key in the parent zone. * Multiple nameservers can answer for a zone using the same zone key, but nonces should strictly be separated by some kind of numbering such as different low-order bits. It seems using separate keys (multiple keys per zone) should be possible. * Traffic analysis has to be checked I suppose the cons can be fixed by "committee". :) Mukund
pgpIqtwiN7U7u.pgp
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
