On Sun, Jun 14, 2009 at 4:35 AM, Florian Weimer<fw@xxxxxxxxxxxxx> wrote: > * Phillip Hallam-Baker: >> 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. The protocol was 'considered complete' in 2000. The people who considered it complete had their fingers in their ears... The zone walking problem was first raised in 2002 by the NSA, response then was LA-LA-LA NOT LISTENING. It was then re-raised when the Europeans stated that they had a legal issue. Then we had another two years of LA-LA-LA while people debated whether the IETF should change its protocols to comply with European Union law while folk insisted that the protocol was absolutely done and could not be changed. You do not speed up deployment of a protocol by ignoring requirements. >> 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. OK, so you have Microsoft and the US government with the ability to control the Internet. And you think that is going to address concerns from other countries? >> 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! If I was not in favor of DNSSEC, there would be no point in arguing to change it. What I am objecting to is the assumption that anyone who criticizes the current DNSSEC specs must be doing so because they want to harm or delay deployment. >> 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? Huh? Why does breaking up the monopoly on registry services amongst multiple suppliers mean a loss of global resolvability? There would be one company in charge of interfacing with the registrars and maintaining updates to the zone. There would be multiple companies that published the zone file prepared. Today there is only one supplier that can credibly perform the specialist task of being the sole publisher for .com. But there are many companies that can prepare the zone file and many companies that can perform part of the distribution. -- 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