Subject: RE: Pimping DNSSEC (was Re: DNSSEC - Signature Only vs the MX/A issue.)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Dec 2006 20:56:25 -0800

> [mailto:[email-masked]] On Behalf Of Shane Kerr

> Isn't this always the case with security though? What is the 
> direct, immediate RoI for putting a lock on your door?

Rarely from securing an existing infrastructure.

Don't expect the existing uses of DNS to drive deployment of the DNSSEC infrastructure. It can only serve those needs after the infrastructure is almost complete.

Deployment of DNSSEC will be driven by the deployment of domain centric security infrastructure such as DKIM and policy based network administrating to address the emerging challenge of deperimeterization.

There is a solid business case there but don't expect early adopters to be the ones who are already satisfied. 

> I think the reason things like DNS and routing security don't 
> get much traction is because there is much lower hanging 
> fruit for attackers. If the end points of the Internet 
> weren't so insecure, then things would be different.

The business case for routing security will be driven by regulation.

> If DNSSEC stabilizes after NSEC3, then DNSSEC could slowly 
> become part of the BCP for network operators. The blocking 
> factor here is the TLD (and the root), which has little or 
> nothing to do with RoI.

Stability is not a necessary condition for deployment. Meeting the criterial considered essential by the key infrastructure providers is.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Tue, 05 Dec 2006 08:24:39 +0000

--On Monday, December 04, 2006 20:56:25 -0800 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> Don't expect the existing uses of DNS to drive deployment of the DNSSEC
> infrastructure. It can only serve those needs after the infrastructure is
> almost complete.

I'm not sure whether this is the same point Phil is making, but inc ase
not, it seems to me the RoI argument is like expecting positive RoI on the
deployment of the first telephone. From a resolver's point of view,
deployment is not going to be particularly useful until there are a number
of authorative servers with secure data to look up; and from an authorative
server's point of view, deployment isn't particularly useful until there
are a number of secure resolvers who know what to do with the data. Whilst
the above is true, I am also hoping it's so blindlingly obvious (being
equally true for most other end-to-end protocols) that people realized it
15 years ago (*).

As far as "no demand for DNSSEC" is concerned, I think it is fair to say I
have not yet driven through parliament square in London only to be slowed
by hordes of protesters carrying banners saying "what to do want? DNSSEC.
when do we want it? Now. Well, as soon as a reasonable deployment plan can
be worked out". However, I do recall going to a meeting a couple of months
ago attended by (amongst others) by one parliamentarian, and a
representative from the UK Department of Trade and Industry, and being
slightly surprised they where perfectly aware of the possibility of various
DNS-related attacks (no doubt discovered through background reasearch for
other Phishing attacks) and that DNSSEC solved most of them. I suspect that
signifies demand. And I suspect major registries aren't spending time
contributing to drafts simply to keep their staff busy...

(*) = I'm afraid I got a bit lost with the argument that
suggested "can't we validate at the caching resolver instead,
that way we don't have to wait for end users to upgrade". Firstly,
didn't we discover the painful way that middle-boxes are often the
last thing to be upgraded (think about new RR-types and firewalls, etc)?
Secondly, to get proper security functionality out of DNSSEC, doesn't
the end user app need to be upgraded? Or there can be no way it
can distinguish between a signed A record and an unsigned one (let
alone between secure denial and insecure denial); unless I'm missing
something vital, that's pretty much equivalent to no security (sure
the cache itself may be more resistant to some attacks, but we have
plenty of end-user machine attacks now).

Alex

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 05 Dec 2006 17:58:23 +0900

Alex Bligh wrote:

> However, I do recall going to a meeting a couple of months
> other Phishing attacks) and that DNSSEC solved most of them.

That's a big surprise, because DNSSEC is not a protection against
most, if not all, of attacks, even when zone administrators are
not compromised, which is as easy as compromising ISPs.

Perhaps, the parliamentarian should also believe DNSSEC were
cryptographically secure.

						Masataka Ohta

---

From: bert hubert <[email-masked]>
Date: Tue, 5 Dec 2006 08:39:43 +0100

On Mon, Dec 04, 2006 at 08:56:25PM -0800, Hallam-Baker, Phillip wrote:

> Stability is not a necessary condition for deployment. Meeting the
> criterial considered essential by the key infrastructure providers is.

And criterium #1 is stability. I've yet to meet serious infrastructure
providers willing to base their network on unstable protocols, where
unstable means "I'll have to upgrade software/protocols/algorithms in the
foreseeable future".

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Alex Bligh <[email-masked]>
Date: Tue, 05 Dec 2006 22:59:18 +0000

> not compromised, which is as easy as compromising ISPs.

Specifically, DNSSEC is a protection against injection / MITM attacks.

Of course there is the possibility that the zone itself is compromised. But
if you can compromise an ISP, far easier to compromise the web site (which
invariably is the app they are considering) in question.

But even if you are right, and DNSSEC does not protect against the majority
of attacks (for some defined set of attacks) I don't see why that implies
it is not useful; it is a useful component in solving the whole problem
(i.e. securing against that set of attacks).

The alternative rational argument is to say "leave DNS insecure, just
like IP is insecure, solve it all at a higher level, for each protocol,
based on certificates etc., and teach apps that in general DNS alone
cannot be trusted". wc -l /etc/services suggests this is an inefficient
route to take (yes, a gross simplification I know, but you get my point).

Alex

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 06 Dec 2006 17:07:34 +0900

> Specifically, DNSSEC is a protection against injection / MITM attacks.

A man working for zone administrators can be the MITM, just as a
man woking for ISPs can be the MITM.

> The alternative rational argument is to say "leave DNS insecure,

Properly implemented and operated plain DNS is secure.

Properly implemented and operated plain DNS is just as secure
as properly implemented and operated DNSSEC.

Both are weakly secure.

Of course, improperly implemented or operated DNSSEC is less secure
than properly implemented and operated plain DNS.

> solve it all at a higher level, for each protocol,
> based on certificates etc., and

PKI is weakly secure.

You can enjoy cryptographic security only when you directly share
secret information with your peer. Security does cost.

						Masataka Ohta

---

From: Alex Bligh <[email-masked]>
Date: Wed, 06 Dec 2006 14:48:34 +0000

> Properly implemented and operated plain DNS is secure.

I would suggest this is a minority view. Else we'd have spent the past
15 years fixing implementations as opposed to protocols.

Alex

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Dec 2006 12:11:42 -0500

> route to take (yes, a gross simplification I know, but you get my point).

I get your point, but I'm not really convinced by it.  (I'm not
actually convinced of anything in this thread yet, though.)

Suppose I am a DNSSEC contrarian.  My argument will go like this
(sorry; it's a little long):

                            *    *    *
DNSSEC, including the newer proposals like NSEC3 and SO, places the
security at the wrong point in the network.  Application designers
have the responsibility to build the security they need into their
applications.  That sometimes means that they can choose not to care
(because loss of data or insecure transmission is acceptable).  That
sometimes means that they can choose to provide fairly minimal
security (because, for example, the cost of better security is more
than the value of the data).  It sometimes means that users will have
to endure inconvenient out-of-band negotiations of security prior to
connection.  And it will sometimes mean that multiple authentication
mechanisms at the ends will be needed (probably with some dependency
on the previous item).

Some will argue that there is inefficiency in that approach, because
several of the security problems could be solved by making the DNS
smarter.  But this violates the principle that one should put as much
of the decision making at the edges; DNS is too central to provide
those security services.  This is the cost of a dumb network/smart
edge model (which is outweighed by the other benefits).

Some will argue that the application designers will make the wrong
decision (and point to /etc/services as one piece of evidence).  But
the failings of previous applications do not entail that some other
part of the Internet should be improved; that is merely an argument
for fixing such applications.  And fixing such applications is again
more consistent with pushing as much of the intelligence as possible
out to the edge of the network.

Some will argue that, because there are applications that really need
the security, but whose users simply aren't willing to bear the
inconvenience of multiple-method authentication and out-of-band
mechanisms.  I, Contrary Guy, answer that if users aren't willing to
bear such inconvenience, then they have in fact decided that they
don't really want the security after all.

Some will argue that the users of the Internet are not technically
sophisticated enough to do the work of out of band negotiation,
pre-loading of others' certificates, and the like.  I, Contrary Guy,
answer that, if such is true, the application designers are shirking
their duty to their users: usability problems are not going to be
solved by remaking the underlying technological support, because the
usability issues will still be there.

Some will argue that the users of the Internet are gullible, and
DNSSEC is needed to protect them.  I, Contrary Guy, answer that the
history of tech fixes to solve the problem of human gullibility is
littered with failure, but has no claim to even one success.  

Finally, there remains the problem in DNSSEC that the costs of it are
not borne, or are borne at best indirectly, by those who want the
additional security it provides.  In order to add this additional
security for some applications, the entire Internet community (or at
least, a significant portion of it) has to bear the burden of
additional load on the DNS and considerably larger DNS packets. 
Moreover, several of those who have that burden to bear are either
contractually unable to extract compensation, or are simply too far
from the end to get such compensation from the users.  In both cases,
the effect will be that the cost will be temporarily externalized,
and then will be internalized in some other way that distorts the
relationship between service and cost.  This distortion is a result
of not following the end to end principle rigourously enough, and
therefore should not be tolerated.
                            *     *     *

I want to emphasise that I'm not sure I buy any of the above, but
each of these is one I've heard.  Together, they seem to be to be a
pretty strong argument that anything complicated to deliver DNSSEC is
unlikely to prevail (so far, I am unable to come up with much of an
argument to completely counter all of the above).  If that's right,
then something less ambitious but simpler, such as the SO approach,
might be a better answer to the extent we think this is a problem
that needs solving.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: bert hubert <[email-masked]>
Date: Wed, 6 Dec 2006 00:13:02 +0100

On Tue, Dec 05, 2006 at 11:01:05PM +0000, Alex Bligh wrote:

> Noone *has* to upgrade anything. If people don't want to upgrade, that's up
> to them. And I thought your argument (now) was that it was not the protocol
> that was unstable, but various implementations thereof through the
> complexity of the protocol - in which case they will chose the stable
> implementations instead.

I was in this case only referring to Phillip Hallam-Baker's statement
that stability was not a necessary condition for deployment - which
statement in my not so humble opinion shows a large "reality gap".

Other messages I've written to this list indeed state that I find the
current protocol specs to be very complex, to the extent that I doubt they
can be reliably implemented.

I'm making this last statement having fully experienced how hard it is to
write software even for unsigned DNS, given the many oddities around
(broken middle boxes, "mandatory optional behaviour" etc).

	Bert

---

From: Alex Bligh <[email-masked]>
Date: Tue, 05 Dec 2006 23:01:05 +0000

Alex

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Dec 2006 08:36:04 +1100

> secret information with your peer. Security does cost.

	Sure humans could inject data in the pre-sign stage of any
	of the parents.  This in no different to the occassional
	bogus NS RRsets that get added to parents today.  I don't
	think anyone that knows anything about security would say
	that this can't happen.  In fact this is the weakest part
	of DNSSEC.

	On the other has these are rare events compared to the the
	attack senarios DNSSEC is designed to protect against.
	i.e.  spoofed responses.

	Now for most zones there are two or three parent zones
	that you need to worry about.  For those that I've seen
	DNSSEC operational plans for I believe them to be secure
	against the DNS server machines being compromised.  At
	worst it results in a DoS attack on the root.

	I believe the root can be secured against all but compromised
	personel.  The root zone is small enough that all data to
	be entered can be transfered by hand.  There is also a small
	enough number of child zones that in person transfers of DS
	records will be possible and/or electronic transfers with
	backup human to human verification will be possible.

	For COM, COM.AU etc. we are going to have to trust that the
	registration system won't be compromised.  I'm not worried
	about the DNS servers themselves being compromised as all
	it lead to is a DoS.

	AU, UK and other small TLD's are in a similar situation to
	the root zone in that it could all be done by hand verification.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Danny Mayer <[email-masked]>
Date: Wed, 06 Dec 2006 21:02:24 -0500

> contributing to drafts simply to keep their staff busy...

I suspect that we will see demand for DNSSEC the first time that a bank
sees a poisoning attack and their customers get redirected to a fake
site and their accounts drained as a result. Phishing attacks can be
alleviated since you can tell technologically that the site is not what
it claims. Their customers will demand it, the bank will be afraid not
to do it, the insurance companies make it a condition of coverage of
losses, etc. Then of course the military have a need for it. Of course
that still leaves the issue of validating resolvers being not being
widely deployed (okay, so only a handful of people have deployed them).
That means that Microsoft needs to implement and deploy them as fast as
possible, since they will have, by far, the biggest affect on making
this happen. They are not the only ones of course but it will have the
biggest impact. So where does Microsoft stand in all of this?

Danny

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Dec 2006 10:29:53 +0900

> 	that this can't happen.  In fact this is the weakest part

That is, DNSSEC does NOT provide cryptographic security.

But, for the other weakest part, see below.

> 	registration system won't be compromised.

Considering that domain names will keep being sold on-line in realtime
with credit card payment, we will use TLS or SSL (or nothing) for secure
exchange of public keys and certificates with the registry.

It means that TLS or SSL (or nothing) is secure enough that we
don't need DNSSEC.

Worse, it also means signature generation system is accessible online.
That is, if the registration server of, say, COM, is compromised,
all the domain names under COM becomes untrustworthy.

This is the weakest part of DNSSEC.

DNSSEC is just as insecure as plain DNS.

							Masataka Ohta