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