Referring to these threads: On 1/21/15, 15:44, "=JeffH" <jeff.hod...@kingsmountain.com> wrote: >Dan York's original msg to dnssec-coord@.. >[dnssec-coord] Thomas Ptacek's rant against DNSSEC (Dan York) >https://elists.isoc.org/pipermail/dnssec-coord/2015-January/000393.html > >Thomas Ptacek replies to various questions re his original post.. > >questions and answers from "Against DNSSEC" >http://sockpuppet.org/stuff/dnssec-qa.html
And on 1/19/15, 13:22, "David Conrad" <d...@virtualized.org> wrote: >In a similar but (IMHO) less specious vein: > >https://www.imperialviolet.org/2015/01/17/notdane.html > >Regards, >-dr. > I haven’t had time to finish writing anything smooth, etc., but have shot off notes to some people privately. Here are some rough points, the essence of how I’d reply. Is DNSSEC worth it? That’s a good question, and one that should be repeatedly asked of any endeavor. In 2008 I presented that DNSSEC wasn’t worth it, then Kaminsky came along and raised the perception of it’s benefit. Now it seems that, standing DNSSEC up against some alternatives, there’s a good reason to re-examine the value proposition. The answer is whatever you want it to be. The reason is, when listing the pros and cons of deploying DNSSEC, assessing the tradeoffs is highly subjective. There’s a strong case to be made in favor of DNSSEC. A lot of the case is circumstantial, however. Is DNSSEC a case of “belts and suspenders?” If an application protocol has it’s own security handshake, does it need to have the DNS responses checked? Well, no, but, not every application protocol has it’s own handshake. We also know that when one application ships with a handshake, that handshake will likely be different from the handshake needed in 5 years or by another application (or even the same application’s new version), leading to a managerial nightmare down the road in operations. The main benefit of DNSSEC is that it scales in many dimensions. Due to the hierarchy it inherits from DNS, the population of agents active in the environment is not bounded. Due to the at-arm’s-length relationship with cryptography, DNSSEC can change the way the handshake is done over time without a need to deploy new code. Due to the dynamic nature of the security associations, DNSSEC can scale around changes to the network. Hierarchy is the favored tool of despots. Hierarchy implies a top, controlling agent. The reason despots like hierarchy is it enables control over more and more subjects and it provides a stable environment. But that doesn’t mean hierarchy is bad - it means it is a useful tool, a tool that when used correctly can be a force for good (scaling and stability). DNSSEC is not innately hierarchical, it inherits that from the system it protects, DNS. There are technical reasons why DNSSEC really is not hierarchical that would take a lot of time to explain. (Really! That is one reason I’ve defended DLV as an operator’s friend.) The one bit of trivia that should be contributed here is that there were research tasks, funded by DARPA no less, to avoid DNSSEC having one unique root for the very same reasons cited in the links - no wanting to place trust in some arbitrary key manager. The research fizzled, but people are welcome to try again. We fizzled over how to, in a scalable way, alert validators which signature providers were preferred, or, to provide the validators a means by which they could decide what signature providers to trust. Those who developed DNSSEC knew so little about cryptography that only the basic “service description” of public key cryptography was used in the system design. 1024 bit RSA keys are an after-thought, no more than a run-time parameter. A revealing bit of trivia is that when the first DNSSEC code bases were developed, compiled and run, RSA’s patent was still in force, hence RSA wasn’t even the favored algorithm in the early code bases. “Algorithm agility” was one of the buzz phrases when designing the old code. If 1024 bit keys are too short or RSA a bad algorithm, use something else. Please, and let everyone know how to follow. The first step in security is having one’s expectations met. When an environment is “as expected” then worries about vulnerabilities, attacks, etc., can be set aside. Pinning, a way to help set up expectations, is one means to know if everything is as it should be. SSH uses this, having hosts store the keys they expect from the other end. There’s one major problem with pinning - it doesn’t do well when change happens. It’s not dynamic or flexible. It would be like a network that, despite many open paths, only one path would be accepted. A single cut would sever communications. Basic texts on transport protocols have very important lessons on why pinning is not a scalable solution. I hate this - every time I try to respond, the email gets longer and longer. (I probably ought to get this into some blog.) Let’s see if I can wrap this up. The most subjective and circumstantial argument for DNSSEC is that there have been many sub-optimal solutions put forth, none of which has stood the test of time. Along the way DNSSEC first had the effect of causing better DNS software to be built. As a direct example of this ISC received funding to build BIND 9 from scratch to prepare for DNSSEC. That alone, new software, improved the overall state of BIND and the DNS. Playing other tricks, like source port randomization, using capitalization in queries for example, had limited success. They helped, but source port randomization was stymied by other network effects like NAT, capitalization stymied by implementations that didn’t fully adhere to the definitional documents (ok, standards if you will). Other solutions just haven’t gained popularity for one reason or another. This is probably not a really strong argument, but is a result of DNSSEC being the most studied approach to solving DNS’s own end-to-end issue (not application end-to-end). In closing, DNSSEC has (at least) two unintended downsides. One is the exposure of zone contents via the NSEC chain (mitigated to some extend by NSEC3 which itself is the source of many headaches for troubleshooters). The other is the enlarged payload being sent over UDP (mitigation of this is hopefully underway). Given the mandate to protect the already running DNS, in a way that would be continuously backwards compatible, piece-wise operable and assuming poor host security, issues like that were unavoidable. I.e., the DNS originally defined an empty, data-set-less, response to be a negative answer, and “dead air” is easily forgeable so something had to be done. And given that DNSSEC deployment was known (already in the 1990’s) to be an uphill battle, none of the underlying DNS definition, including the use of UDP, could be changed. So DNSSEC is defined to ride over UDP without any DNSSEC-means to mitigate the side effects.
smime.p7s
Description: S/MIME cryptographic signature
