Subject: Re: secure entry point

From: Miek Gieben <[email-masked]>
Date: Tue, 1 Apr 2003 09:32:56 +0200

[On 01 Apr, @00:16, Edward wrote in "Re: secure entry point ..."]
> That's how I defined it in the 1998 secure resolver, using a file 
> called "/etc/sresolv.conf" as a replacement for /etc/resolv.conf. 
> It worked well.

same here, in my little perl implementation I used resolvsec.conf,
and I also stored the IP numbers there. I really think that for a 
resolver a SEP should be defined as: a key + ip address(es).

grtz Miek

--
:wq!

--
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: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Apr 2003 11:38:39 +0200 (CEST)

> resolver a SEP should be defined as: a key + ip address(es).

if a zone is moved from one name server to another, why should you need to
update your resolver configuration file?

the only ip address based entry point we really need have in the dns is
the root.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Apr 2003 11:54:23 +0200 (CEST)

On Tue, 1 Apr 2003, Miek Gieben wrote:

> how do you securely get the ip address for a secure entry point? There is no
> secured delegation that you can check.

you don't. since you have the key you know that the zone is secure, but
you do not know where to find it.

you could make it a stub zone in your caching nameserver, but that is
separate issue.

> if the root is secured it is simple, but even then the definition of a secure
> entry point is: key + root ip adresses

how to find the root is separate from securing it.

	jakob

---

From: Miek Gieben <[email-masked]>
Date: Tue, 1 Apr 2003 11:47:33 +0200

[On 01 Apr, @11:38, Jakob wrote in "Re: secure entry point ..."]

grtz  Miek

--
:wq!

---

From: Miek Gieben <[email-masked]>
Date: Tue, 1 Apr 2003 12:09:45 +0200

[On 01 Apr, @11:54, Jakob wrote in "Re: secure entry point ..."]
> you do not know where to find it.

but I do think this is an issue. Not knowing where to find the zone is
fatal, even if you do have to key and know the zone should be secured.
Spoof the nameserver ip, and the resolver gets bad data, there is no
way the resolver can guard against such an attack.

And if you change nameservers you will probably also change the key, so
the resolver already has to update something. With little extra work
the ip number can also be updated. (This is a bold statement, but nameserver
changes without changing the key will be rare, I think)

grtz Miek

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Apr 2003 12:14:52 +0200 (CEST)

> way the resolver can guard against such an attack.

the resolver can always detect if it had received bad data.

> the resolver already has to update something.

why would you ever change the key if you change nameserver? distributing
the signed zone and signing it is very different.

	jakob

---

From: Miek Gieben <[email-masked]>
Date: Tue, 1 Apr 2003 12:23:13 +0200

[On 01 Apr, @12:14, Jakob wrote in "Re: secure entry point ..."]
> the resolver can always detect if it had received bad data.

yes.. so if I spoof the secure entry IP for .nl, the whole of .nl is bad

> the signed zone and signing it is very different.

I'm in the process of writing down how DNS operations will look like when
DNSSEC is deployed. Maybe we should take this up on the cafax list.

grtz Miek

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 1 Apr 2003 13:30:20 +0200

> yes.. so if I spoof the secure entry IP for .nl, the whole of .nl is bad

Yes.. Bad luck I'd say.

DNSSEC does not provide for a way to check the delegation. If a
delegation points you to the wrong server your lost; that is to be
seen as a DOS attack.

If you want to be 'resistant' to drop of connectivity to the root than
have your recursive servers be slave of your local domains. That can
be done independend of your "trusted-keys".

DNSSEC does not give a bit about where data came from. Let's not add
that dependency in the resolv.conf you (provide buckshots to shoot ones
foot off :-) ) 

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2003 08:53:31 -0500

I would recommend this in a resolver implementation, but defining 
this as part of the protocol would take too much debate time.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2003 09:07:28 -0500

>update your resolver configuration file?

Because I'm paranoid.

There's a sliding scale from brittle to resilient.  Given any system, 
with it's place on the brittle-to-resilient scale, once you add 
security to it, it slides towards brittle (because you've restricting 
it from entering some states).  The big challenge in adding security 
to a resilient system is to maintain as much resiliency as possible.

This points to not fixing the IP numbers of the authoritative servers 
in the secure resolver configuration.

However, securing a brittle system is easier than securing a 
resilient system.  The more restricted the set of states a system can 
enter, the easier it is to prevent it from entering an insecure one.

Entering the IP numbers does make the resolver more brittle, but 
that's under my (the resolver operator) control.  Essentially, I've 
moved the resiliency up into wetware - someone has to configure again 
when a change is made.  Retaining resiliency by requiring more manual 
intervention is something only the paranoid should do, that's why I 
like the idea, but wouldn't push for documenting this as standard 
behavior.

>the only ip address based entry point we really need have in the dns is

Not exactly true - LLMNR and disconnected networks come to mind. 
(One of my scenarios was a ship a sea.)

---

From: Rob Austein <[email-masked]>
Date: Sat, 05 Apr 2003 16:07:34 -0500

After reviewing the whole thread, I think the following is the key
issue:

At Mon, 31 Mar 2003 16:20:44 +0200, Miek Gieben wrote:
> 
> [On 31 Mar, @15:51, Donald wrote in "Re: secure entry point ..."]
> > If you trust a public key to sign DNS data and can verify the signature
> > over that data, it doesn't make any difference where you got the data
> > from. There is no reason to worry about the IP address of the
> > nameserver.
> 
> But this opens up a huge dos attack (this has nothing to do with "dnssec does
> help against doc attacks"). You will only have to spoof the IP address of a
> secure entry point and you're done. The resolver will notice that the signatures
> do not match and will declare the thing BAD.
> 
> This can easily be prevented by also configuring secure entry point ip adresses. 
> (you already have to configure the secure entry point keys anyway, so this adds
> little more work)

Either I'm missing something, or this DOS attack is present in any
case, because nogoodniks can intercept your queries and send you
spoofed responses using the real name server's IP address.  DNSSEC
can't prevent this.  All DNSSEC can do is give you somewhat better
criteria by which to determine whether something bad has happened.