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 19:12:17 +0100

Paul Vixie wrote:
>>>...
>>>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.

The assumption was that there would be no DS.

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

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: Edward Lewis <[email-masked]>
Date: Wed, 9 Jun 2004 14:20:10 -0400

(Earlier I sent this privately to Ben because my "radio" was turned off.)

At 12:08 +0100 6/9/04, Ben Laurie wrote:
>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?

RFC 2065-era assumption: only authoritative data is signed.

1) The fact that an NS exists is something established at the parent. 
What's in the RDATA is established by the child.  So we have a split 
authority problem.

2) DNS does not require, so far as I know, perfect coherence between 
the child's version of the NS set and the parent's version.  Relaxed 
coherence allows for "operational bumps."  Being able to tolerate 
that is what fuels DNS's incredible ability to scale.  (Systems that 
are too tight generally are too rigid and don't survive jolts.)

The "weakness" of the NS set in the eyes of security is a great asset 
in the eyes of scaling.  It's ironic, I know.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

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

Paul Vixie wrote:
> 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.

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.

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

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: Ben Laurie <[email-masked]>
Date: Thu, 10 Jun 2004 17:26:59 +0100

Paul Vixie wrote:

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

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: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 09:42:38 +0100

Paul Vixie wrote:

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

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.

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

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.