I really see no value in debating whether DNSSEC is 'end to end'. Clearly DNSSEC is only one component in a security solution and whether it is 'end-to-end' depends on what you decide to call an endpoint. Now I have serious reservations about the design of DNSSEC. The current design would establish the root key holder as the perpetual controller of the DNS. That is not acceptable to the Russian, French or Chinese delegations in ICANN, nor should it be. In the long term it is inevitable that some idiot in Congress will decided to get on hid hind-hoofs and propose a bill to drop Cuba, Palestine out of the root or recognize Khalistan or some other idiot mischief. They will gain considerable publicity at the cost of a considerable amount of chaos for the State Department and breaking up the DNS root. This is not just a concern for the fringe posters trying to set up alternative DNS roots, it is exactly the type of concern that any competent national security apparatus should be thinking about. It is the reason why the Palestinian minister for Information bothers to meet with the President of ICANN. This may seem like a pointless arguments over symbolic issues, but those are precisely the type of issues that lead to riots, bombs and assassinations. Bin Laden would almost certainly not have attacked the World Trade Center if it had been called Manhattan Office Blocks 1&2. If people attempt to deploy with the current design they will cause ICANN to fracture. Moreover, there is no support from any major platform vendor, (mere aggregation in a Linux distribution does not constitute support unless typical Linux administrators configure and install). DNSSEC was designed to create a security infrastructure for the Internet, leveraging the existing DNS infrastructure and adding the necessary security to DNS to make that possible. DNSSEC is not a security solution for the DNS and never has been. If people want to deploy DNS Security then the task has to be given to a group that is not so invested in their existing solution. The reason that the process has taken fifteen years so far is that each time a real-world requirement has been raised, the response of the group has been to stick their fingers in their ears and sing 'LA-LA-LA-NOT-LISTENING' for several years. Then after finally listening to the requirement they claim it is too late to consider it because the process is taking so long. When Kaminsky discovered his cache poisoning vulnerability, some companies put out PR saying that the issue was already known, as if that made things better somehow. The real problem with the time it has taken to deploy DNSSEC is that nothing else could be considered while it was on the table. But the lack of end-to-endedness is not a problem, nor is end-to-end security even a desirable property in a security PROTOCOL. Alice and Bob are people, not finite state automata. And the fact is that Bob is a cluless pinhead who has neither the interest, nor the competence to configure his Lindows/X box. Bob recognizes this fact which is why he outsources configuration of his security to McAntec. He doesn't keep money in his home under the mattress either, he keeps it in a bank. It is far more important for a security protocol to meet the constraints of real-world deployment and use than to be 'end-to-end' secure. During the crypto-wars, the end-to-end property was considered essential because we did not want to provide an opportunity for Louis Freeh to install a wiretap. As such it was a deeply flawed strategy. Insisting on end-to-end resulted in security solutions that almost nobody used. The portion of Internet email traffic secured by PGP and S/MIME combined is negligible. We get far more practical security from deployment of STARTTLS at the SMTP transfer level. In DNS, the vast majority of DNS resolvers are maintained by hosting providers. Thus no true end-to-end service is possible. To secure the DNS we need to adopt an entirely different approach. This has to start with a serious effort to engage the platform providers. The original model of DNS is that each endpoint uses and trusts the local DNS server. This is bogus. It might have made sense twenty years ago, it does not make sense today. I use the Internet service at Panera because I need packets shipped, not because I trust them or their service. Setting aside the problem of establishing the WiFi customer agreement, each Internet machine should only accept DNS service from one single source. Deployment of DNSSEC as currently configured requires the Internet endpoint to perform the taks of trust chain management. That assumes that what is on the other end is a personal computer or a serious embedded systems controller. But while the speed of the fastest processors continues to increase, the number of 8-bit and slower processors in use increases at an even faster rate. The most appropriate security model for DNS is not the end-to-end model that we have failed to deploy for fifteen years. It is a hybrid system in which each Internet endpoint establishes a shared TSIG key with their trusted DNS service and the trusted DNS service authenticates its input using a combination of TSIG and DNSSEC approaches. Such a model would not be purely end-to-end but it would allow end users to effectively achieve far greater security than they have today without a major impact on platforms. Instead of every host being vulnerable to cache poisoning we first reduce that by several orders of magnitude to just the DNS servers, we have not eliminated the problem but we have reduced it to a manageable scope. This model would also create more interesting opportunities for DNS service providers and allow an eventual restructuring of the way that DNS operates. While the DNS is in theory an infinitely (OK 100-ish layer) nested hierarchy, there are in practice only three levels of singificance: the root, the TLD and the domain name owner (yes, Domain names are property). >From my point of view there is only one generic TLD that matters and only one that ever will matter. ICANN's attempts to introduce new TLDs will not create competition, they will merely increase the opportunities for rent-seekers (including ICANN) to extract unjustified rents. Neither .net nor .org adds value, they merely increase the cost of defending against domain squatters. The way to create competition in DNS services is within the .com registry. First separate out the task of preparing the zone from the task of servicing it. This has already been achieved to some degree with ANYCAST distribution at multiple sites round the world. Add in an independent monitoring service to measure response times of the distribution points and you have the basis for a competitive market. In addition to competing on response times, distribution providers could offer additional security enhancements such as TSIG authentication of responses as premium services. The Internet is now a commercial enterprise. That means both constraints and opportunities. The constraint is that we need to think commercially if we are going to see new infrastructure deployed. The opportunity is that with only a small amount of imagination it is possible to bring immense capital investments into the system. The same goes for the countries that will ensure that the US does not establish itself as the perpetual controller of the DNS through its control of ICANN. Instead of treating them as obstacles, design technologies to co-opt them. Instead of this in-your face, 'we have the ball and you are not getting it' attitude, give the other countries a share in signing the root. One option would be key splitting, another would be a quorate root of the type Phil Zimmerman originally proposed for PGP but never implemented. The current situation is a stalemate that not meeting my security needs, is not meeting the national stakeholder's sovereignty needs and is not meeting anyone's commercial needs. So why is it insisted that we do nothing till DNSSEC somehow deploys itself? Anyway, that is my thinking on the topic and people who want to work on it can contact me offline. I am off to the basement to build daleks. -- 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