Subject: RE: NSEC synthesis and the NSEC Next Domain Name field

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 12 Jun 2004 07:41:50 -0700

This thread on dynamic signing of NSEC records is pointless.

If you tool up to do this you might as well just sign every response. That
would allow the entire protocol stack to be dramatically simplified.

You could even go one stage further and do ephemeral key exchange then
authenticate the responses via MACs.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Don Stokes
> Sent: Saturday, June 12, 2004 7:44 AM
> To: [email-masked]
> Subject: Re: NSEC synthesis and the NSEC Next Domain Name field 
> 
> 
> 
> Paul Vixie <[email-masked]> wrote:
> >geoff sisson proposes that servers who care deeply about 
> zone walking and
> >who can't afford the crypto hardware nec'y for NSEC 
> synthesis just keep a
> >general purpose NSEC sitting around, like one at the first 
> non-apex domain
> >name with a target of the apex, and just use this on all 
> NXDOMAIN responses.
> >this clearly "proves" that all names do not exist, even if 
> they do, but
> >since the only valid use for such an NSEC is to validate an 
> NXDOMAIN or
> >NOERROR response, nobody is actually allowed to care whether 
> the names
> >that NSEC "proves" do not exist, actually don't exist.  the danger is
> >replay, but geoff says he's willing to trade that risk off 
> against others.
> 
> I'm thinking about that.  It gives me the shivers, because 
> I'm not sure
> about all the corner cases.  For example, if a TLD has (excluding
> RRSIGs):
> 
> 	example.	SOA ... 
> 			...
> 	\001.example.	NSEC	example. NSEC RRSIG  ; For denials
> 			...
> 	foo.example.	NS	ns1.example.com.
> 			DS	...
> 			NSEC	\001.foo.example. NS DS NSEC RRSIG
> 			...
> 
> and an attacker forges:
> 
> 	foo.example.	NS	hostile.example.net.
> 
> in response to a query for name.foo.example, a security aware resolver
> might ask <foo.example. DS ?> and be met with the "denial" NSEC:
> 
> 	\001.example.	NSEC	example. NSEC RRSIG
> 
> "proving" the DS doesn't exist.  Now, that should also be taken as
> proving that the NS doesn't exist as well, invalidating the cached NS
> records, however, I can see buggy implementations forced by 
> an attacker
> into doing this in two phases missing that and interpreting the
> "missing" DS as an unsecured delegation to hostile.example.net. 
> 
> Maybe I'm just too pessimistic. 
> 
> 
> >the reason i mention all of this is, an NSEC says nothing 
> about zone content,
> >it's only a way to prove the nonexistence of a qname or 
> <qname,qtype>.
> >there can be other existing and populated names within the 
> range given,
> >and that's not a problem.  as long as the range given 
> "covers" the qname,
> >then the NSEC is a valid response.
> 
> I take the point about caching of NSEC records, and agree 
> that at least
> in the short term, nothing more than the status of the query should be
> inferred from them.  However, the presence of a cached NSEC record
> indicates the non-existence of the intervening names, and I'd like to
> see the door kept open to using that information in the future. 
> 
> Consider: if the root has a valid NSEC chain, then a forwarder faced
> with lots of queries for <something>.localdomain" will soon get:
> 
> 	lk.	NSEC lr. ...
> 
> from the root servers and could answer all "localdomain" queries with
> that.  Once all the corner cases are worked out, I think this could be
> quite valuable.
> 
> Allowing NSECs to cover existing records would close the door on using
> cached NSECs in this way, and I think such NSECs should be disallowed
> from the outset.
> 
> 
> Personally, I think that DoS avoidance in NSEC synthesis, even if one
> doesn't have crypto gear aboard, can be achieved to a large degree
> by queueing all requests for records that don't exist to a 
> low-priority
> NSEC synthesis process via a fixed-length queue.  If the 
> queue is full,
> just drop new queries on the floor.  They'll get retried, 
> probably to other
> servers, and the worst case is that legitimate lookups for things that
> don't exist anyway will time out.  One would still have 
> static NSECs for
> things that do exist, which are a lot more important, and appropriate
> caching of synthesised NSECs could also mitigate such attacks.  (I'm
> figuring that in real life, most legitimate denials will be 
> for a small
> number of domains, so a usage-weighted cache would mean that 
> queries to
> common non-existent domains would get cached synthesised NSECs even if
> the crypto process was totally swamped.)
> 
> 
> >> By extension, and I think some explicit wording in the 
> -protocol doc
> >> would be required for this, one could interpret "foo.example. NSEC
> >> foo.example NSEC RRSIG" as meaning that there are no RRSETS for
> >> foo.example, *nor anything below it* other than the NSEC & RRSIG.
> >
> >i would not interpret it that way at all.  "empty 
> nonterminals" and all.
> 
> By "below" I meant below it in the tree, not in the (ordered) zone.
> 
> >> For any name in the zone that exists, at zone build time, 
> generate either:
> >> 
> >> 	<name> NSEC <name> <existing-rrsets> NSEC RRSIG
> >> or
> >> 	<name> NSEC \001.<name) <existing-rrsets> NSEC RRSIG
> >> 
> >> The latter case is required if there are any names below 
> <name>, but
> >> should (must?) not be used if <name> is a delegation point.
> >
> >by the resolution and validation rules as i understand them 
> at this moment,
> >the zone cut would trump the NSEC.  in other words you'd get 
> a delegation
> >rather than an NXDOMAIN, and the content of the "latter 
> case" NSEC target
> >would never be relevant.  and as before, if you can't 
> enforce it, don't
> >make it a rule.
> 
> Fair enough.  Might pay to make "delegation trumps NSEC" an 
> actual rule
> tho.
> 
> >> Alternatively, one could generate in all cases:
> >> 
> >> 	<name> NSEC <null> NSEC RRSIG
> >> 
> >> where <null> is an as yet undefined magic value that says, 
> "there is no
> >> next domain name field", possibly even using one of the 
> reserved values
> >> of the label type field, e.g a byte value of 0xA0.
> >
> >that's most intriguing.
> 
> It would make synthesis, or just plain lying, a lot tidier.  
> 
> Using the reserved label code points (01 or 10) would set a precedent,
> so should be thought through carefully, but if they are introduced as
> part of the definition of NSEC, shouldn't pose a problem.  I think the
> effect of using 0xA0 would be to make code point 10 effectively mean
> "arbitrary values"; future developments might find uses for 0xA1 and
> so-on through to 0xBF.  That still leaves code point 01 reserved.
> 
> Other possibilities for <null> include:
> 
> - a "magic" name, eg "NULL."  Yuck.
> 
> - The root.  Nice and small, but might complicate things with the real
> root.
> 
> - A compression pointer with an offset of 0, i.e. 0xC000.  This "can't
> happen" even if compression is allowed (which it isn't in an NSEC),
> because the offset is relative to the start of the message, which will
> be the message header.  Therefore 0xC000 will never turn up in a real
> compressed name.
> 
> I think I prefer the reserved code point approach myself.
> 
> -- don
> 
> --
> 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/>
> 

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