Hi Paul On Mon, Oct 13, 2014 at 02:22:48PM -0400, Paul Wouters wrote: > >I would expect that anyone taking up DNSCurve and proposing it in this > >forum would do what I did and use it as a starting point and make > >modifications. > > You want different spokes to jam in the dns caches? Or a different spoke > to stab into the authoritative DNS servers' CPU? Or a different spoke to > stab into the DNS proxies and deep packet firewall inspectors and DNS > transparent proxies? > > There are very good reasons dnscurve was not picked up by the IETF. And > it really doesn't make sense to pick up dnscurve for only the transport > hop encryption part, because: > > 1) it is hacked into the DNS using NS record overloading with severe > limitations > 2) it spews non-DNS traffic over port 53 > 3) it hardcodes crypto parameters to the One True Curve > 4) it was designed to run on authoritative servers, not dns caches > > Really, dnscurve was about killing the dns caching resolver. Why on > earth would anyone propose to use it to secure those same entities the > protocol insists on killing? > > dnscurve has no place in an IETF dnspriv discussion other than to serve > as an example on how to not secure resolver-stub communication.
I came into this late, and I didn't know before that this discussion was
only about resolver-stub security. In any case, in reply to the above,
to me it appears that there are prior opinions against DNSCurve (and
maybe there are good reasons for it).
Will you explain why stub-resolver communication cannot be secured with
the concepts in DNSCurve? The NS record would not apply, but I don't see
anything in the packet formats itself that would make it useless. Any
other scheme would also require key distribution of either a shared key
or a public key between resolver and stub. Are there additional
requirements apart from transport security?
Even though DNSCurve in its current form has issues, I don't think it's
right to dismiss it from discussion and not take ideas from it. The
central idea in DNSCurve is that the DNS message goes into a safe box
and the receiver uses the associated crypto params in the packet to open
the box and use the DNS message in it. There is no prior handshake
required, and you can have 1 datagram query -> 1 datagram reply. Reading
the NaCl code, it seems one can use the same single public-key operation
for future messages with the _beforenm() and _afternm() functions for
performance, albeit at the expense of maintaining state.
It may use DJB's crypto and fixed key sizes in the 2 packet types in the
draft, but each packet has the type identifier in the header. Nothing
stops adding additional types with different algorithms, keysizes and
nonces, keeping the concept of the dns-message-in-a-box.
Mukund
pgpDZl6aIRfPe.pgp
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
