* Phillip Hallam-Baker: > 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. The browser PKI shows that root key material can change hands, so I don't see what's perpetual about it. It's not that anybody wants to hold those keys, either. Those bits are a bit like inmates of the Guantánamo Bay detention camp. Everybody demands that the United States Government releases them, but nobody wants to take care of them. > 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. So how do you explain the delay caused by NSEC3 standardization? The protocol was considered complete in 2004. > 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. In the real world, TLDs are driven by the demands of the secondary domain market. The secondary market does not care about name resolution, only name ownership, so it doesn't need DNSSEC. > In DNS, the vast majority of DNS resolvers are maintained by hosting > providers. Thus no true end-to-end service is possible. Wrong. The majority of resolvers are maintained by Microsoft. Microsoft could ship the KSK for the root to customer machines in a security update. As it happens, in this case, the KSK wouldn't even be the penultimate key, showing that the debate over who holds the KSK is quite pointless. Now that we've got automatic software updates, we don't even need a signed root. > 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. Ah, so you're still strongly in favor of DNSSEC deployment, you're just hiding it pretty well! It makes sense to ignore stub resolvers for the time being, right. > 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. Uhm, when you can get signed delegations from .ORG (but not .COM), the zone adds value. > 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. Huh? Why would I buy a delegation from a zone which is run in a way that doesn't guarantee world-wide resolvability even at the zone level itself? _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf