Subject: On dynamic NSEC

From: Simon Josefsson <[email-masked]>
Date: Thu, 11 Nov 2004 13:04:26 +0100

Quoting <http://www.xmpp.org/ietf-logs/[email-masked]/2004-11-10.html>:

> [13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it
> on the fly. minimally cover. idea has been posted to ML. not in
> archive. use NSEC mechanism, good things, can use current resolvers
> to validate. would mean can deploy DNSSECbis without enumeration
> properties, if can implement this in server....
...
> [13:07:54] <ggm> Proposed way forward: fast-track epsilon in this
> group, review, try to see if will work, publish asap. so that things
> can be deployed today. in same time, continue on other solutions,
> without makeing choices.

There seem to be some assumption that online signing of dynamically
generated NSEC with "epsilon" domains coexist with DNSECbis.

I'd like to remind people about section 2.3 of protocol-09:

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record.
...
   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRset at any particular owner name.  That is, the signing process
   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
   not the owner name of any RRset before the zone was signed.

This text imply to me that you cannot invent new owner names for NSEC.

I believe the above MUST's are not required for interoperability nor
are they necessary for successful operation of DNSECbis.

It seems the text may cause problems, if dynamic signing of NSEC with
epsilon domain names is used together with DNSECbis.

I raised this problem, in the context of lying NSEC, during the
DNSECbis last call.  It was apparently ignored.

http://article.gmane.org/gmane.ietf.dnsext/5339

I maintain that the MUST cannot in general be verified by clients, and
hence should not be part of the specification.  Further I believe that
the text prevent deployment of NSEC alternatives.

Thanks,
Simon

--
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: Mark Andrews <[email-masked]>
Date: Fri, 12 Nov 2004 02:14:39 +1100

> > This is a known issue. In order to deploy NSEC+epsilon, we have to
> > change the text.
> 
> IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion
> path until DNSSEC-ter.

	Maybe temporary.  Once implemented there is less pressure
	to implement other online signing solutions.  To get rid
	of enumeneration in deep zones online signing appears to
	be the only solution.

	Once there is a online signing solution it is unlikely that
	a second solution will be implemented.

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Nov 2004 22:19:13 +0000

...
> the text prevent deployment of NSEC alternatives.

i agree with the first part of this.  the specification should include
no server constraints beyond those that will be invisible to clients.

i do not agree with the second part of this.  nsec alternatives will be
developed, and they might take advantage of errors in the original specs
(like proscriptions against server side activities which weren't
distinguishable by clients).  in other words, this is a loophole, let's
drive a truck through it.

Alex Bligh <[email-masked]> wrote:

> So I'd been working under the assumption the wildcard lookup would
> be changed to exclude NSEC only labels (hence NULL and NSEC aren't
> equivalent). If my assumption is wrong, then you are indeed right,
> NULL and NSEC *will* break wildcards - in exactly the same way,
> and, AFAICT, completely.
> 
> But I may have missed something here.

i think you missed two things.  first, see above.  in this case the loophole
created by the dnssec-bis spec error (that of outlawing something in the
server that will not affect the client or be distinguishable to the client)
allows you to simply say, in a later spec, that a server who "violates" this
provision of dnssec-bis by creating on-the-fly NSECs for with epsilon names
at nodes with no real (unsynthesized) rrsets, must treat the zone as having
no rrsets at these synthetic names, for all purposes related to wildcards.

second, your argument pertains to a zone signer, which changes zone content.
in the case of an on-the-fly signer, which does not change zone content, it
is very possible to get exactly the treatment we'll probably want, without
invalidating any conforming clients of the dnssec-bis protocol.

(i wish i wasn't such an expert at exploting loopholes in specifications...)

---

From: Alex Bligh <[email-masked]>
Date: Thu, 11 Nov 2004 23:19:43 +0000

--On 11 November 2004 22:19 +0000 Paul Vixie <[email-masked]> wrote:

> second, your argument pertains to a zone signer, which changes zone
> content. in the case of an on-the-fly signer, which does not change zone
> content, it is very possible to get exactly the treatment we'll probably
> want, without invalidating any conforming clients of the dnssec-bis
> protocol.

Assuming we cache NSEC records, which is presumably desirable, what
prevents a caching resolver relying on a cached NSEC to fail to match an
otherwise closest enclosing wildcard?

IE how the wildcard spec is written at the moment, if a resolving
client sees
	foo	IN	NSEC 	bar
in example.com, it should not match a query for QNAME=foo.example.com.,
QTYPE=MX against
	*	IN	NSEC	baz

Right?

In which case, if bar=S(foo) and foo does not exist in the unsynthesized
zone, the above is easy enough for a miscreant to put in the nameserver
yes?

I agree if there is a hole in the original spec (i.e. the original
spec is too prescriptive) we can drive a truck through it, but I thought
the original prescription that NSEC records only exist where other
non-NSEC labels exist was there for a well-defined reason (so not to
break wildcards) - IE I don't think this /is/ a hole.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Fri, 12 Nov 2004 17:10:10 +0000

--On 12 November 2004 01:00 +0000 Paul Vixie <[email-masked]> wrote:

> caches don't match wildcards.  only an authority server can do that.
> otherwise a server who had cached "*.dom" and "foo.dom" might decide
> that a query for "bar.dom" matched the while card, even if in the
> authority server, "bar.dom" actually exists.
>
> (not that a synthetic rr would have a nonzero ttl in the first place.)

OK. Let me simplify a bit, drop the caching nameservers, and at the risk of
looking stupid:

Take a zone example.com:
*	IN	MX	foo
bar	IN	MX	baz
dummy	IN	NULL
dummy2	IN	TXT	"fred"

It uses NSEC epsilon. That means for every possible label, there is a
synthetic NSEC record, and per Rob's proposal, also a synthetic NULL
record. Synthetic I am taking to mean "not in the original zone loaded into
the nameserver, but created algorithmically so it appears under all other
circumstances to be in the zone"

I then make the following queries:
1. type=NSEC, label=xxx.example.com
2. type=MX, label=xxx.example.com
3. type=ANY, label=xxx.example.com
4. type=MX, label=dummy.example.com
5. type=MX, label=dummy2.example.com

What do I get?

Surely type 1 HAS to return (at least)
	xxx	IN	NSEC	S(xxx)
or the whole epsilon NSEC stuff doesn't work

Surely (2) is indistinguishable from (4) if there is a NULL record
synthesized?

Surely (2) is indistinguishable from (4) and (5) unless NSECs are processed
differently from NULL's in the wildcard algorithm?

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sat, 13 Nov 2004 15:16:18 +0000

Paul,

>> OK. Let me simplify a bit, drop the caching nameservers:
>>
>> Take a zone example.com:
>> *		MX	10	foo
>> bar		MX	10	baz
>> dummy		NULL
>> dummy2		TXT	"fred"
>> www		IN	A 	1.1.1.1
>> zzz		IN	A	2.2.2.2
>>
>> record.  Synthetic I am taking to mean "not in the original zone
>> loaded into the nameserver, but created algorithmically so it appears
>> under all other circumstances to be in the zone"
>
> with the proviso that i didn't understand the need for a NULL RR, i'm
> tracking you so far.

OK, Rob Austein suggested synthesizing a NULL RR to avoid changing the
requirements of 2.3 - I was pointing out that didn't help. So let
us assume for the minute *NO* NULL RR's are synthesized (i.e. it
operates in breach of 2.3 but we hope this doesn't cause any harm).

> given that there is a wildcard, there will be no NXDOMAINs for this zone.
> therefore every NSEC will have a real owner name.  so, i'm with you so
> far.
...
> response to (5) would be NOERROR/NODATA as with (4).  i appear to be lost.
> can we have this discussion over again, except this time can you do it
> without the synthetic NULL RRs, and can you explain the non-dnssec parts
> of each reply so i'll know what covering dnssec metadata will be applied?

OK, so I think what should happen WITHOUT epsilon signing  - i.e. if normal
NSEC records are put in (note I've stuck a couple more records in to make
it obvious) is something like:

1. My mind is fried and I know can't work out what that returns but
   it's not relevant for the point
2. xxx	IN	MX	foo
3. xxx 	IN	MX	foo
4. NOERROR/NODATA
5. NOERROR/NODATA

With epsilon signing, there is an NSEC record for every possible label
query (either synthesized or not). So, queries (2), and (3) should
hit a zone with RR's against the label "xxx", something like
	xxx	NSEC	S(xxx)
but no RR of type MX. Therefore, *if the current DNSSEC-bis lookup
algorithm is followed*, the presence of an RR of any type (even NSEC) will
result in that RR being the closest encloser for xxx, and (2) should thus
return NOERROR/NODATA as the closest encloser has no RR of type MX. This
thus breaks wildcard MX (and as far as I can tell this was the reason for
2.3). The solution of course is for the server NOT to count NSEC records
(or at least synthetic NSEC records) as closest enclosers. If no NSEC
records are considered closest enclosers (at least for QTYPES other than
NSEC), then 2.3 can be dropped in its entirety as far as I can see, and
this also helps with some of the arguments against hashed NSEC' sharing the
same namespace and interfering with wildcards.

Perhaps I'm making some mistake here.

My point to Rob was that adding NULL RR's to give technical conformance
of synthentic NSEC's to 2.3 does not help as they equally break wildcards
and cannot be excepted in the same manner from closest encloser rules
(i.e. it makes things worse).

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sun, 14 Nov 2004 13:07:23 +0000

--On 13 November 2004 20:43 +0000 Paul Vixie <[email-masked]> wrote:

>> query (either synthesized or not).
>
> no, it matters whether it's synthesized or not.  if there's a real nsec rr
> then it would have an impact on the wildcard search algorythm.  a
> synthetic nsec rr, being made from whole cloth, can be defined as having
> no impact on the wildcard search algorythm.  this is possible only
> because the synthesis and the wildcard search are both done in the
> authority server. [1]
>
>> ... The solution of course is for the server NOT to count NSEC records
>> (or at least synthetic NSEC records) as closest enclosers.
>
> yes.
>
>> If no NSEC records are considered closest enclosers (at least for
>> QTYPES other than NSEC), then 2.3 can be dropped in its entirety as
>> far as I can see, and this also helps with some of the arguments
>> against hashed NSEC' sharing the same namespace and interfering with
>> wildcards.
>
> not unless the hashed nsec's were synthetic.

OK. I am now going to play your game of driving a truck but this time
through a hole you created :-) If you are correct with [1] above, and
there is no reason to doubt you, then your assertion works because
the epsilon NSECs are created by the authority server according to
a specific algorithm. Provided that the algorithm is used, the resolver
would have no way of telling whether they are in fact synthetic NSECs,
or whether they aren't.

So, for example, the zone I create and give to the authority server
could have (and I'm assuming S(foo)=foo\000, S(foo\000)=foo\000\000 etc.)
	*		IN	MX	2.2.2.2
	foo		IN	A	1.1.1.1
	foo		IN	NSEC	foo\000		[A]
	foo\000	IN	NSEC	foo\000\000		[B]

The authority server would produce synthetic NSECs (for instance
	foo\000\000	IN	NSEC	fooo\000\000\000	[C]

But I can't see a resolver can tell the difference. That doesn't matter
because (as you say) the wildcard search (which is the only thing it
matters to we think) is carried out on the authoritative server.

Now given these NSEC records have to be signed, there is nothing (it seems
to me) to stop us saying hashed NSEC' records are the same. They could all
be created on the authoritative server, and all signed on the authoritative
server. In that way, the authoritative server can exclude them from the
wildcard lookup algorithm.

And if that's the case, then you can use the same argument I've used above
to say that NSEC' records could IN FACT not be synthesized - they could
come from the original zone, and still omitted from the wildcard lookup
algorithm - the resolver wouldn't be able to tell the difference.

IE, if you can get away with an authoritative server treating synthetic
NSEC epsilon records differently in terms of the wildcard lookup
algorithm, then as far as I can see, logically the same must be
true of non-synthetic NSEC' hash records.

In which case we know that removing the requirement in 2.3 and amending
the wildcard search algorithm to remove hashed NSEC' records is not
going to be problematic.

I would add that you might as well remove the requirement for NSEC records
(as opposed to hashed NSEC' records) to be treated that way, except that in
the above example there is I suppose a theoretical need for a QTYPE=MX
query on the zone to produce a different result for QLABEL=foo\000
and QLABEL=foo\000\000 (as only one is synthetic).

[Note, side argument: I am not sure that we should not in that case not
have put a note to the effect that resolvers should not rely on servers
following 2.3: just as we are driving a truck through what we think
an open hole in that 2.3 can be violated because the resolvers must
fulfil other parts of the specification and not, for instance, do
their own local optimizations for wildcard searches by relying on
(say) cached records, others writing from the resolver end may conclude
that in fact THAT restriction is a whole in the spec THEY can drive
a truck through because it doesn't matter if they violate rule (X) because
all servers will be following the restrictions in 2.3 so breaking
rule X won't damage anything will it? - visions of 2 trucks driving
through dark holes and colliding in the middle]

Alex