Subject: End to End Secure Protocols are bogus.

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Jun 2009 10:43:50 -0400

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/

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jun 2009 08:22:11 +0900

> I really see no value in debating whether DNSSEC is 'end to end'.

Being end to end has practical benefits, which is why the Internet
has been so successful, which is why some people have been insisting
on a false statement that DNSSEC were secure end to end.

For example, the following statement of you in another subthread:

> The
> controller of the DNS.

means DNSSEC involves the root key holder as a third party and not
end to end.

Feel free to see no value on your statements.

> whether it is 'end-to-end' depends on what you decide to call an

According to the terminology of David Clark, DNSSEC is not end
to end.

> that made things better somehow.

The issue is that the concept of "bailiwick" is broken, which
was already pointed out.

Kaminsky's attack can be protected against by proper handling
of glue, without which DNSSEC cache can also be poisoned.

							Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Jun 2009 20:28:46 -0400

End to end ceases to have any value whatsoever once people attempt to
codify it into a rigid ideology.

Security does not respond at all well to ideological mandates. We have
tried to deploy end-to-end solutions and failed. In many cases we
could easily have succeeded if we had been less inflexible in the
approach.

You are not doing David any favors whatsoever here. He is not a
dogmatic ideologue. The end-to-end paper was originally written when
rigid ideologues such as yourself considered the telephone network to
be the ultimate communications infrastructure.

Above all, it is an argument against dogmatic approaches to system
architecture. You are completely misrepresenting his work.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Jun 2009 06:23:38 +0900

> codify it into a rigid ideology.

Exactly.

That was what happening by those people with false claims that
DNSSEC were secure end to end.

The reality, however, is that attacking DNSSEC is as easy as
plain old DNS by poisoning cache with forged certificate
through glue (e.g. Kaminsky's attack).

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Sun, 14 Jun 2009 10:35:06 +0200

> current design would establish the root key holder as the perpetual

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.

> '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.

> 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.

> 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.

> authenticates its input using a combination of TSIG and DNSSEC

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.

> increase the cost of defending against domain squatters.

Uhm, when you can get signed delegations from .ORG (but not .COM), the
zone adds value.

> 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?

---

From: Ralf Weber <[email-masked]>
Date: Sun, 14 Jun 2009 16:51:43 +0200

Moin!

> don't even need a signed root.
Can you elaborate on that? Last time I checked most of the Windows OS I
know got there resolver IP from the DHCP server which either is the ISPs
resolver, or the address of the broadband gateway, which DNS proxies to
the ISPs resolver. I know how non recursive validating stub resolvers
should work, I just haven't seen them deployed widely. Even business
customers which is the majority of customers we have tend to use our
(the ISP) resolvers directly . That might be also the reason why
governments love to use them to block content ;-).

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

Schütze Deine Umwelt | Erst denken, dann drucken

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland  
* Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *

Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies *  
Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400

---

From: Florian Weimer <[email-masked]>
Date: Sun, 14 Jun 2009 17:17:57 +0200

> the ISPs resolver.

This doesn't have to change.  In DNSSEC, the recursor and validator
functions are separate.  The current approach to DNSSEC validation
promoted by Microsoft is different, though (the clients don't do
validation on their own, but use a secure transport to the recursive
resolve, which also performs validation).  

However, root hint updates are generally rolled out through software
updates (not just by Microsoft, but by every other vendor, too).  It
should be possible to use a similar mechanism to distribute trust
anchors (it seems that some DRM stuff works in this fashion, too).
For those who want (or need) to opt out of the global root, a local
override needs to be provided.

But I can't really see widespread deployment of non-recursive
validators.  The protocol doesn't support well a scenario in which a
host with more trust anchors forwards a query to a cache with fewer
anchors, anyway.  For Debian, we'll likely recommend to run a
validating recursor with a small cache locally, and not something like
lwresd.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Jun 2009 09:42:40 -0400

> 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.

> 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?

> 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.

> that doesn't guarantee world-wide resolvability even at the zone level

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Jun 2009 20:44:52 -0400

Some, but not all censorship attempts may be justified.

For example, consider the case where you want to discourage users from
visiting known phishing sites or domains that have been registered for
botnet herders to regain control after a communications loss.

We probably don't want that type of filtering added into the ICANN
root, but it might well be the sort of thing that an enterprise might
want to implement for its internal network.

While that type of infrastructure makes a form of political censorship
somewhat more straightforward, it only enables a pretty weak form of
censorship that is easily evaded. In general, I think we should stop
worrying about enabling government censorship in security protocols.
If we care about stopping censorship we should build a protocol that
is designed from the ground up with the purpose of being censorship
proof. Such a protocol would probably use USB keys for transport
rather than the Internet or a mixture of Internet and USB. Worrying
about incremental possibilities is pointless, the enemy already has
far greater capabilities than people worry about.

On Sun, Jun 14, 2009 at 10:51 AM, Ralf Weber<[email-masked]> wrote:
> COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel
> +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *
>
> Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht
> Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400
>
>
>
>
>
>