While I agree that deployment of DNSSEC is important in order to enable improved application security, it was not originally designed to address DNS security issues and only addresses one DNS security issue and a not very interesting one at that. Unfortunately deployment of DNSSEC has come to represent the answer to any and every DNS security problem. It is the right answer to the wrong question. There are four separate DNS security issues: 1) Quality of data going into the DNS system. 2) Quality of data coming out of the DNS system. 3) Robustness of the DNS infrastructure in the face of attack. 4) Governance of the DNS infrastructure. DNSSEC only addresses item number 2. In addition there are several groups who look to the DNS and see a potential control point to be used to protect Internet users. Consider the case that there is a phishing attack underway and the target site is u2842.com. A lot of police forces wonder what purpose it serves to provide resolution service for that address when users are being directed to a site that will attempt to defraud them. And another group of people look at the problem and ask if they want the Chinese government to be able to block access to YouTube.com when the news is inconvenient. At the moment the general assumption is that the Internet community will decide which objective to prioritize, stopping crime or blocking censorship attempts. But it is not quite that simple, in the final analysis, I think we lost the cryptowars rather then won them. Everyone was so desperate to prevent Louis Freeh from gaining control that we developed technical standards that have poor usability and have seen negligible usage. Less than 1% of Internet users know what S/MIME or PGP is about and almost nobody uses it every day. What is happening in practice is that China, Iran, Russia and the rest are working out ways to achieve their censorship objectives while the potential benefit we might see from crime reduction is not being seen. The biggest concern to the national security community at the moment is the third risk, the robustness of the system in the face of attack. Vast sums are spent each year keeping the root zone and the major TLD online despite the ongoing DDoS attacks. This is a situation that is very profitable in what is effectively a cost-plus contract situation. But it is not necessarily one that can always be solved by throwing more and more hardware at it. Take the root zone, we have an impressive infrastructure there that is designed to respond in miliseconds with an answer that almost never changes and a question that never changes. The right answer in 1985 is not necessarily the right answer today. The biggest weakness I see with the 'let DNSSEC solve it' answer is that the only place we have where we can expect that information to be used today is at the recursive resolver. That would be a reasonable solution if the architecture of the DNS was that every end point machine would choose a trusted DNS server and stick with it. Unfortunately, we have this bizarre notion that every machine should by default trust the DNS server advertised in DHCP - another protocol without authentication. The next biggest weakness is the lack of support from Apple and Microsoft. There are certainly ways that both companies can be browbeaten into providing checkbox compliance with the standard. But without the enthusiastic support of the engineers and the willingness to adapt the protocol to real world needs the checkbox compliance will not be worth very much. I think that we need an entirely different approach here. We need to start from a security analysis of the DNS and the Internet infrastructure as it stands to day and is expected to develop over the next few years. Then we need to look at the constraints imposed by the current infrastructure and then we need to work out what tools in our existing box can be used to provide the necessary controls, which areas we need to develop entirely new controls and which areas we need to develop additional tools because the existing ones are too hard to deploy. The most significant change we could make to the DNS architecture as it stands is to break the assumption that every DNS server is equivalent. This is clearly a bad assumption. They may be intended to provide equivalent results but they are certainly not all as trusted. And the fact that I will ship packets over a network does not mean I trust their DNS resolution. 2009/7/9 Russ Housley <housley@xxxxxxxxxxxx>: > Dear colleagues: > > Following the success of the Internet Society's IPv6 panel held at the IETF 74 venue, I want to make you aware of panel event to be held during the IETF 75 week in Stockholm, Sweden: > > Securing the DNS: Towards a more secure Internet > 11:45am - 12:45pm (UTC+2), Tuesday 28 July > Clarion Sign Hotel, Stockholm, Sweden (opposite the IETF 75 venue) > Light lunch provided; registration is free > > The Domain Name System (DNS) is one of the critical operational elements of the Internet, creating a "human environment" that allows names to be mapped to host addresses across the Internet. But the DNS was established with no inherent security mechanisms, making it vulnerable to certain malicious activities, such as DNS spoofing, where attackers make false assertions about DNS data in order to misdirect traffic to unwanted sites. > > Efforts are underway on several fronts, developing better Internet security technologies and practices through open standards development and the collaborative work of developers, operators, and industry. One key effort is DNSSEC (short for DNS Security Extensions) - a set of open standards developed to authenticate DNS data using public key infrastructure to digitally sign DNS records, providing a high level of security to core transactions. It does not solve all online security issues, but it is an important step towards a more secure online experience. > > Leaders from across the Internet community are actively engaged in work to drive the broad deployment of DNSSEC and other standards for continuous improvements in Internet security. > > In this session - designed to make these issues accessible to a broader audience - the Internet Society's Leslie Daigle will lead a distinguished panel of some of the world's leading developers, administrators, and operators of Internet infrastructure. What are their experiences? What problems have they overcome? And what do they see as the next steps towards a more robustly secure Internet? > > All are welcome to participate, but seats are limited, so please register in advance. More information, including free online registration at: > > http://www.isoc.org/dns > > For those unable to attend, an live audiocast will be available - check the website above closer to the date for details. > > Russ Housley > IETF Chair > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf