Saturday, October 11. 2008DNSCurveTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Surely it throws an important baby out with the bath water, since it doesn't prevent someone controlling the server from spoofing answers in the same way as DNSSEC.
Thus, no matter how good the cryptography, any weakness on any .NET or root server, and the Internet is owned. Where as a key issue for ICANN in deploying DNSSEC is to make sure they are signing elsewhere in a secured environment. Secure the key, or secure all the servers - seems an easy choice.
Might seem a small issue if you are bottom.of.the.pile.sld.tld, but if you are "." (how many root servers are there these days? I think slaving root is the most useful suggestion in the paper in that sense) or "mil." or "mod.uk." you want a chain of trust all the way to the top.
Of course one might argue that the problem is that different DNS users have widely differing security requirements, so one size doesn't fit all. But I'm not sure we want to be deploying more than one system.
The advantage of DNSSEC is rather marginal, and comes at a very high complexity, that is in itself likely to lead to security problems.
Securing the DNS servers is not much harder than securing the signing servers, and practically they are likely to be the same servers except for the root.
My view is that DNSCurve may well be better way forward. We routinely trust that the servers we deal with are operated securely, the current problem with DNS are due to the lack of authetication of packets oassing over the network, and spoofing vulnerabilities.
Where high security is required, application level security is required in any case, so the highly complex and probaly unreliable DNSSEC is not justified.
|
QuicksearchBlogroll |