* 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf