Subject: additions to dnssec-bis-updates-04.txt

From: Roy Arends <[email-masked]>
Date: Tue, 19 Dec 2006 16:43:02 +0100

As promised (though a little late) here are my quirks from the dallas-ietf 
presentation on DNSSEC-bis omissions:

One rant on DNSSEC-bis is that it groups empty-non-terminal response types 
as "name errors" instead of "no data errors" (section 3.1.3.2 of RFC 
4035). I think it was Rob Austein who explained during the WG session that 
the term "Name Error" used in DNSSEC-bis does not necessarily reflect 
"rcode=3 (name error)". In hindsight, this is purism, and does not create 
any holes in the validation logic. This is not all that important, so my 
suggestion here is to remove the following part in dnssec-bis-updates:

2.2.  Empty Non-Terminal Proofs

   To be written, based on Roy Arends' May 11th message to namedroppers.

   The editors are trying to figure out whether what's really required
   here is a discussion of the relationship between DNS RCODEs and
   DNSSECbis.

Other points of my presentation in Dallas were: 

(1) ancestor versus parent terminology

I'd suggest avoiding 'parent-side' terminology in favor of 'ancestor' for 
NSEC Origin checks. For every existing name (except for the empty 
label/root), there exists a spanning NSEC in an ancestor zone. Not just at 
the parent zone. So the following rule for the type-bit-map must be true 
for proof of absence of name check when NSEC ownername is an ancestor of 
the QNAME: (NOT DNAME) AND ((NOT NS) OR SOA). My guess is that you wanted 
to state this in section 2.1 of the update document, but that needs to 
rewritten. This is somewhat a purity issue, since the validator can't 
distinguish parent from grandparent or further ancestors.

(2) gaping hole:

validation in rfc4035 for unsigned delegation needs an NSEC for proof of 
absence of DS records. Section 5.2 of RFC 4035 states that the validator 
needs to check for the absence of DS type and absence of SOA type, but 
fails to mention to check for the presence of NS type. If this is not 
checked, spoofed unsigned delegations can be used to claim an existing 
signed record is not signed.

(3) spoofing cname into nonexistence.

If response is of type nodata: check NSEC for absence of CNAME type, 
otherwise a claim for nodata at name X/type Y might be a spoof, since the 
type might exist at the canonical name for X.

(4) expanding wildcards/wildcard no data response

Both response types need a proof that the wildcard is at the closest 
encloser. The closest encloser can be determined by comparing QNAME to 
both ownername and nxtdname of the NSEC and take the nearest common 
ancestor. Every NSEC in a response MUST have the same closest encloser 
(this is fact, not a requirement). i.e. validator must check this way that 
there is no closer wildcard match.

Hope this helps,

Roy Arends
Nominet UK

--
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: Edward Lewis <[email-masked]>
Date: Tue, 19 Dec 2006 11:11:42 -0500

>presentation on DNSSEC-bis omissions:

Dallas?  Or Montreal?   Or San Diego? ;)

>suggestion here is to remove the following part in dnssec-bis-updates:

I don't think redefining terms in this way is just a violation of purism.

I can't think back 3 IETF's though to recall the conversation.

>distinguish parent from grandparent or further ancestors.

This is only an issue when you are staring at two NSEC sets/records 
owned by the same name. In this case, it is just the parent that 
matters.

E.g., for www.foo.bar.example.com, assuming all zones are just one 
label deep, yes, you have a lot of NSECs covering the name.  Assuming 
that www.foo.bar.example.com is not a delegated point, then all of 
the NSEC's will have different owner names (and signed by different 
domains).

If www.foo.bar.example.com is delegated from example.com, then there 
will be two NSEC's, both owned by www.foo.bar.example.com. You can 
distinguish which is which by the bitmap.

A domain name will not own records in more than two zones, ever.  If 
there are records in two zones, it is parent and child we are seeing.

(Am I missing a point here?)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Roy Arends <[email-masked]>
Date: Tue, 19 Dec 2006 17:38:42 +0100

> Dallas?  Or Montreal?   Or San Diego? ;)

Dallas.

> label deep, yes, you have a lot of NSECs covering the name. 

This was exactly my point.

> Assuming 

Yes.

> (Am I missing a point here?)

No, you're not. 

You want to be sure the NSEC record is from the correct zone, lets say 
"from the zone that has the authority to make that claim", and not from an 
ancestor zone. 

I was ranting against the use of the word 'parent' instead of ancestor. 
that is all.

Roy Arends
Nominet UK

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Dec 2006 12:14:26 -0500

>"from the zone that has the authority to make that claim", and not from an

The only time the bit map will give a hint whether the NSEC is right 
or not is when it is parent/child involved, when the owner name is 
the same between two NSEC choices.

It's possible that an NSEC owned by an ancestor label will not have 
any delegation information.

www.foo.bar.example.com - A AAAA NSEC DNSKEY RRSIG
foo.bar.example.com - SOA NS NSEC DNSKEY RRSIG or NS DS NSEC DNSKEY RRSIG
bar.example.com - TXT
example.com - same as foo-bar-...
com - ditto
. - just the second half of the above

Come to think of it, none of the ancestor NSECs would cover the last 
anyway - all of the next names would be at or before the next name 
down.

>I was ranting against the use of the word 'parent' instead of ancestor.

In this case, it would seem that parent is more accurate than ancestor.

Also, keep in mind that the NSEC has to be signed by it's zone - that 
ought to give away the authority of the NSEC.  The only reason the 
bitmap comes up is if you want to avoid having to look at the RRSIG.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Roy Arends <[email-masked]>
Date: Tue, 19 Dec 2006 19:52:37 +0100

> the same between two NSEC choices.

root: com NSEC edu NS DS
tld:  example.com NSEC lewis.com NS DS 
sld:  www.example.com NSEC example.com A

QNAME is www.example.com

The spoofed response contains: com NSEC edu NS DS

This is obviously from an ancestor (grandpa in this case), not the parent.

This was about terminology, not the rules itself, so I don't see what the 
rest of your response about rules and ways to check, etc, etc has to do 
with my point about terminology.

Roy Arends
Nominet UK

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Dec 2006 14:25:06 -0500

>with my point about terminology.

What's the point about terminology?  The doc, in 2.1, talks about 
distinguishing between parent-side and child-side NSEC through the 
use of the bit map.  This same check is unique to the parent-child 
issue, it isn't pertinent to any zone up the tree (toward the root).

In your example, I don't see this working.  "com NSEC edu NS DS" 
doesn't indicate a span from com to edu, it covers the span from the 
last name in the com *domain* (not zone) to edu.  I see this:

   com ... www.example.com .... lastnamein.com ... edu

with the NSEC saying there is nothing after lastnamein.com until you 
get back to edu.  The NS bit says this.  So the NSEC is not covering 
the QNAME.

In 2.1, the words there are about the problem of having this:

       example.com NSEC foobar.com NS DS DNSKEY RRSIG NSEC
       example.com NSEC a.examppe.com SOA NS DNSKEY RRSIG NSEC

Are you saying that there's a missing case of mistaken identity - 
that we need to be clear that a NSEC with an NS or DNAME bit means 
the span is from the end of the owning domain?  Truthfully, the span 
is always from the end of the owning domain - the NS bit just reminds 
us that there are names lower in the tree, that the owning domain is 
not terminal.

I think that 2.1 is accurate - any parent-side NSEC can be misused 
(via misinterpretation) to deny data below it, the section doesn't 
limit the damage to only the zone below.

Looking upwards, it isn't just the parent-side NSEC whose bitmap 
matters.  But 2.1 doesn't say to only look up to the parent-side 
NSEC, as opposed to the ancestor.

OTOH, 2.1 isn't exactly clear..."both RRs at that ownername and at 
ownernames with more leading labels, no matter their content" I don't 
understand the point of that comment.

---

From: Roy Arends <[email-masked]>
Date: Tue, 19 Dec 2006 21:34:48 +0100

Jaap Akkerhuis <[email-masked]> wrote on 12/19/2006 08:44:04 PM:

> The dictionary at my MAC tells me that parent can also mean ancestor.

Ok wijsneus :) 

.. an anscestor (grandpa in this case), other than the parent ..

Roy Arends
Nominet UK

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 19 Dec 2006 20:44:04 +0100

jaap

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Dec 2006 09:28:20 +1100

>    here is a discussion of the relationship between DNS RCODEs and

	A NSEC record prove that there at no names, with records,
	between the owner of the NSEC record and the Next Domain
	Name in the zone which owns the NSEC record.

	This is not the same as there are no names in the covering
	span.

	You can determine which empty names exist in the covering
	range of the NSEC by taking the NSEC's closest encloser and
	the Next Domain Name. If the Next Domain Name is not the
	closest encloser and call that E.  Strip the left hand label
	from E and if that is not the closest encloser you have
	found a empty name that exists in the span.  If that name
	end in a wildcard label you have found a empty wild card
	label. Keep striping labels from E until you encounter the
	closest encloser to find all the empty names that exist in
	the range.

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