Subject: Philosophy behind unsigned NS records?

From: Ben Laurie <[email-masked]>
Date: Wed, 09 Jun 2004 12:08:47 +0100

Contemplation of issues related to NSEC2 has made me wonder why NS 
records are not signed at the delegation point.

I realise that they are not authoritative at that point, but it seems to 
me that there's a (small) win gained in the case where the nameservers 
are in a signed zone but the zone being delegated is not signed (which 
is probably quite a common scenario in the early days of DNSSEC). Did I 
miss something?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
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: "Scott Rose" <[email-masked]>
Date: Wed, 9 Jun 2004 09:18:15 -0400

Not sure what you mean here.  What would that gain us?  If I get it right, a
delegation to an unsecure child would look like:

Answer section:
			blank
Authority section:
 sub.example.com		NS
				RRSIG (NS)
Additional
 ns.sub.example.com	A
 hash__sub.example.com	NSEC2  bitmap w/o DS RR.

There still needs to be some information about the DS, or lack thereof.  I
don't see what signing the NS set gains us with this.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ben Laurie
> Sent: Wednesday, June 09, 2004 7:09 AM
> To: DNSEXT WG
> Subject: Philosophy behind unsigned NS records?
>
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 09 Jun 2004 16:04:33 +0100

> don't see what signing the NS set gains us with this.

It means that the delegation can't be spoofed. Note that the delegation 
could be to a nameserver in a signed domain, and so its A record could 
also not be spoofed.

Cheers,

Ben.

---

From: Roy Arends <[email-masked]>
Date: Wed, 9 Jun 2004 17:38:07 +0200 (CEST)

> could be to a nameserver in a signed domain, and so its A record could

A security aware caching resolver would overwrite non-authoritative signed
data with authoritative unsigned data in this case. Delegation point NS
records (and optional glue address records) are authoritative elsewhere,
so they'd need to be signed elsewhere. The additional cost of delegation
point signatures are placed on the parent, while the gain is minimal.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Wed, 09 Jun 2004 17:25:02 +0000

> > ...
> > There still needs to be some information about the DS, or lack
> > thereof.  I don't see what signing the NS set gains us with this.
> 
> It means that the delegation can't be spoofed.

the threat in this case is being delegated toward a serverset who can't sign
its responses with the key denoted by the parent's DS.  this is a denial of
service attack, but it would be easier to launch one using congestion than
by query-id guessing.

> Note that the delegation could be to a nameserver in a signed domain,
> and so its A record could also not be spoofed.

none of that matters.  the responding subdomain servers can either sign its
responses using the key given in the parent-DS, or it can't.  no amount of
NS-signing by the parent will cause a third alternative to appear.

at first glance there appears to be an opportunity to improve the situation
by offering trusted delegations to unsecure zones.  however, this just moves
the query-id guessing attack down one level.  if the subdomain zones are not
secure, then it doesn't help that the parent-NS that delegates to them is
signed and trustworthy.

dnssec isn't just end-to-end, it's root-to-leaf.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 09 Jun 2004 19:12:17 +0100

> service attack, but it would be easier to launch one using congestion than

The assumption was that there would be no DS.

> dnssec isn't just end-to-end, it's root-to-leaf.

Well, there may be other reasons to rely on the nameserver (or avoid 
spoofing thereof) - for example, it is at the other end of some IPSEC or 
VPN authentication, or it is inside a trusted network.

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 09 Jun 2004 18:41:09 +0000

note: since this is about clarifying the existing documents rather than
about whether NSEC2 should be adopted (or what DNSSEC-TER should look like),
i don't believe that the chairs' radio silence request applies.  if i'm
wrong, i'd like a chair to clarify the radio silence request in public.

> > the threat in this case is being delegated toward a serverset who
> > can't sign its responses with the key denoted by the parent's DS.
> > this is a denial of service attack, but it would be easier to launch
> > one using congestion than by query-id guessing.
> 

if there's no ds, then there's no value added by signing anything in the
delegation.

> spoofing thereof) - for example, it is at the other end of some IPSEC
> or VPN authentication, or it is inside a trusted network.

that configuration is outside of dns proper, and is not a topic area for
dnssec-bis.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Jun 2004 12:22:47 +0100

> wrong, i'd like a chair to clarify the radio silence request in public.

Indeed - the motivation for the question was that I couldn't find any 
explanation in the documents. It might be a good idea to say something 
about it.

> that configuration is outside of dns proper, and is not a topic area for

I'm not sure what you're saying here - do you mean it shouldn't be 
discussed at all w.r.t. DNSSEC, or do you mean that it isn't relevant to 
finalising the docset?

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 14:24:32 +0000

> discussed at all w.r.t. DNSSEC, or do you mean that it isn't relevant to

i think that the use of dns over non-ip networks like tunnels is not
described anywhere, and so the dnssec-bis protocol and docset has no
reason to mention the configuration you've described.  it's the same
as NAT.  there's no rfc that describes dns response rewriting by NAT
boxes, and so, dnssec-bis behaves as though such rewriting doesn't
occur.  this may be a bad thing, and it may be that there should be
rfc's about "implications of nat on dns" and "implications of private
secure tunnels on dns" and so on.  but today there are no such, and
the dnssec-bis design team would be foolish to try to cover undefined
working conditions.

note that the lack of signatures on nonauthoritative delegation NS RRsets
has simplified the design, and changing it in the 11th hour isn't an
option because of the impact such a change will have on other parts of
the model.  if it's to be changed, then it's really a dnssec-ter issue.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Jun 2004 17:26:59 +0100

> the model.  if it's to be changed, then it's really a dnssec-ter issue.

I was not suggesting it should be changed in dnssec-bis, but I do think 
it should be explained and possibly also mentioned in the security 
considerations.

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 17:15:54 +0000

> > as NAT.  ... and the dnssec-bis design team would be foolish to try
> > to cover undefined working conditions.

> ... but I do think it should be explained and possibly also mentioned
> in the security considerations.

why is that, exactly?  should we also mention that it won't work over
sneaker-net or avian-net, or after global thermonuclear war?  i'm not
*just* being peevish, i'm trying to point out that there are a lot of
actual, potential, or imaginable circumstances under which dnssec-bis
would be unusable or inapplicable.  why is this particular one worthy
of specific mention in the document?

some years ago an earlier instance of IAB gave us a "statement regarding
the end-to-end nature of internet communications" or some such.  i thought
it was a mistake, since even at that time, real internet communications
used very different models than the one described in that statement.  but
the one thing that statement gave us was well defined starting conditions
for subsequent (or even previous) protocol specifications.

using dnssec to get a secure path from some trust anchor (like the root,
maybe, someday) to some delegation point, where the NS RR was trustworthy
but the A RR maybe or maybe not so and the zone definitely not, on the
basis that perhaps some validators will have out-of-band methods of
trusting the communications with or content received from the servers for
such zones, is so far away from dnssec-bis's "starting conditions" that
you might just as well talk about how dnssec-bis would work for harry
potter if his wand spoke tcp/ip.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 09:42:38 +0100

> of specific mention in the document?

The fact that delegated NS records are not signed opens them up to 
spoofing, which is a security consideration. Explaining why they are not 
signed is just being friendly to people not party to discussions on this 
list.

> potter if his wand spoke tcp/ip.

I was giving examples of why someone might care, not suggesting that 
these examples should be important to, or even documented by, dnssec-bis.

Cheers,

Ben.