Duane points to a recent debate, something about DNSSEC and its added value, which resulted in this comment by one Thierry Moreau: DNNSEC is almost worthless! The reasons appear to be based on an analysis of three usage models, and each usage model heads for the rocks for one reason or other. Thierry points out that user #1 is not interested, user #2 is small, and user #3 will be not be allowed. The analysis is worth a read, as it is nicely laid out (regardless of whether you agree or not).
What is going wrong with DNSSEC? From the outside, the results are clear: it was never used. In my terms it breaches parts of my 4th hypothesis, which is, in short, "Usability is Number One." To start off with:
#4.1 Zero Users means Zero SecurityThe most common failure mode of any security protocol is not being used by users, at all.
There have been thousands of attempts at secure protocols in recent Internet times. Many did not get completed, many were completed but were rejected as too hard to use, and many great protocols missed the boat and were swamped by bad protocols. These are therefore all failures; their delivered security is zero. Zip, zilch, nada.
Perfect security, multiplied by zero users, always equals Zero security. Try it with any variation of zero you like, and any grade of security. Count up as many security projects as you like, and look at the very strong correlation: Security perfectly reaches zero with all known forms of mathematics, if it is has zero users.
Only a delivered protocol that protects and ships packets for actual, warm, live, talkative users can deliver security. A good protocol with some gaping holes will always outperform a perfect protocol that remains undelivered, in security terms. A good protocol in widespread use will generally outperform a better protocol that is poorly used.
Again simple mathematics tells us why: a protocol that is perfect that protects one person perfectly, is still limited to that one person. The mathematics of security says that is a one. If you can reduce your protocol's theoretical security from 100% to 99%, and get ten users, that then means you can reach 9.9, in delivered security to those ten users. Approximately. If you can reduce to 98%, but gain 100 users then your security reaches 98.
Security is as delivered to users, and is summed across them. Therefore, it goes up almost perfectly with the number of users. By far the biggest determinant of security is then the number of users that you can gain. Consider that first and foremost.
This result certainly applies to DNSSEC, and the hypothesis title of Usability may hint at why. Or not.
Posted by iang at June 14, 2008 04:24 PM | TrackBackJust a quick note. This person (Thierry M.) is pushing his own patented technology, called "TAKREM", in the IETF working group that deals with DNSSEC protocol development. Please don't take his article as "the" view of the working group as a whole.
Posted by: Chris at June 14, 2008 01:47 PMThere is also the issue of who might make money off it. I've commented that ssl server certification authority industry have somewhat backed DNSSEC ... but it represents a significant catch-22 for them
http://www.garlic.com/~lynn/subpubkey.html#catch22
currently ssl domain name server digital certificates represents binding between domain name and public key. the authoritative agency for domain names is the domain name infrastructure. ssl domain name server digital certificates where (at least partially) justified by perceived vulnerabilities in the domain name infrastructure (the same domain name infrastructure that is the authoritative agency for domain names).
the root trust for domain names is the domain name infrastructure ... so part of DNSSEC could be viewed as improving the integrity of the domain name infrastructure as part of eliminating systemic risk for ssl domain name server digital certificates. This can be achieved by having public key presented as part of registering domain name ... and then future communication with domain name infrastructure needs to be digitally signed ... which can be verified with the previously registered, onfile public key.
This can also be used to reduce the cost of ssl domain name digital certificates. Currently certification authorities require a ssl digital certificate application to include a whole lot of identification information. Then the certification authority has to perform error-prone, expensive and time-consuming identification matching process with the information on file (for the domain name) with the domain name infrastructure.
With an on-file public key, certification authorities can just require that ssl domain name digital certificate applications be digitally signed ... then the certification authority can replace the time-consuming, expensive, and error-prone identification process with a much more reliable and inexpensive authentication process ... verifying the digital signature with the public key on-file with the domain name infrastructure.
the catch-22 for the ssl domain name certification authority industry
1) improvements in integrity of domain name infrastructure mitigates some of original justification for ssl domain name digital certificates
2) if general public can also start doing trusted real-time retrieval of on-file public key ... it further eliminates need for ssl domain name digital certificates as well as general demonstration about not needing digital certificates for trusted public key operations.
Posted by: Lynn Wheeler at June 14, 2008 02:05 PMThere is something wrong with the link , check your markup .. you added an extra ..(the marc.info link)
Posted by: anonymous at June 14, 2008 08:59 PMAnyone interested in DNSSEC problems should look at Thomas Ptacek's series of articles on this, which seems to be pretty much the final word on DNSSEC issues, and specifically "why don't we have DNSSEC deployed yet?". It's at http://www.matasano.com/log/case-against-dnssec/ (although the final parts have been in preparation for quite some time now).
Posted by: Peter Gutmann at June 16, 2008 03:49 AMhttp://ds9a.nl/secure-dns.html and http://ds9a.nl/dnssec/
may also shed some light on the issue.