On Mon, 13 Oct 2014, Phillip Hallam-Baker wrote:
DNSCurve was originally proposed to do a rather different job and it is actually better at that job than DNSSEC in my opinion.
I agree that DNSSEC sucks at the job it is not supposed to do :)
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'm not set for any of the proposed solutions yet, but: - I like the idea of using (D)TLS (but on port 443, possibly with ALPN, and not using any kind of "starttls hack" to put non-DNS traffic on port 53) - I like the idea of using regular format DNS payloads over port 53 but nervous about more problematic bad DNS software Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
