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: Alex Bligh <[email-masked]>
Date: Thu, 11 Nov 2004 13:10:45 +0000

> the text prevent deployment of NSEC alternatives.

Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't
be fiddling with DNSSEC-bis now (not sure we even can).

Both epsilon-based dynamic signing, and hashed NSEC'-based mechanisms will
require an alteration to/addition to DNSSEC-bis, and will need to make
their own (separate) way down the standards track. The former alteration is
clearly smaller, and hence progress should be quicker (though I suspect
due to key exposure and other factors, its audience may be more limited).

Alex

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Nov 2004 09:16:42 -0500

>be fiddling with DNSSEC-bis now (not sure we even can).

I'd put it this way - we shouldn't be fiddling with the DOCUMENTS 
that are in production.

But don't let DOCUMENTS get in the way of RUNNING CODE.  Proposed 
Standard status recognizes that there may need to be adjustments to 
the text to describe reality.

I said in another group "it's never too late to comment on the 
protocol, but it's too late to comment on the document" in the 
context of a document that we had handed to the IESG.

Simon is right about the passage.  Alex is half right that fiddling 
with DNSSECbis - we ought not fiddle with docs so implementers and 
operators can get to work.  But never let the bureaucracy of what's 
been written get in the way of real technical progress.

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

I would have been at the meeting, but I was busy raking the leaves from
the (now) empty non-terminals in my yard.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Nov 2004 14:31:03 +0000

> the text prevent deployment of NSEC alternatives.

This is a known issue. In order to deploy NSEC+epsilon, we have to 
change the text.

Cheers,

Ben.

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 11 Nov 2004 09:47:03 -0500

At 09:16 11/11/2004, Edward Lewis wrote:
>I'd put it this way - we shouldn't be fiddling with the DOCUMENTS that are 
>in production.
>
>But don't let DOCUMENTS get in the way of RUNNING CODE.  Proposed Standard 
>status recognizes that there may need to be adjustments to the text to 
>describe reality.
>
>I said in another group "it's never too late to comment on the protocol, 
>but it's too late to comment on the document" in the context of a document 
>that we had handed to the IESG.
>
>Simon is right about the passage.  Alex is half right that fiddling with 
>DNSSECbis - we ought not fiddle with docs so implementers and operators 
>can get to work.  But never let the bureaucracy of what's been written get 
>in the way of real technical progress.

To amplify what Ed said, at this point we do not know the FULL extent
of the changes needed to the DNSSECbis documents, when we know that we
will issue an update to DNSSECbis documents.
We also do not know at this time for sure that anyone will deploy
the +/-epsilon changes, there might be engineering reasons not to do that
in which case the updating the protocol is a mute point.

Please start the discussion on what +/- epsilon will be like, once the
WG understands and has consensus on the modified protocol, the appropriate 
changes to protocol described in DNSSECbis will be made.

         Olafur

         Olafur

---

From: Roy Arends <[email-masked]>
Date: Thu, 11 Nov 2004 15:53:12 +0100 (CET)

> This is a known issue. In order to deploy NSEC+epsilon, we have to

IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion
path until DNSSEC-ter.

Roy

---

From: Alex Bligh <[email-masked]>
Date: Thu, 11 Nov 2004 15:11:20 +0000

--On 11 November 2004 09:47 -0500 "Ólafur Gudmundsson/DNSEXT co-chair" 
<[email-masked]> wrote:

> will issue an update to DNSSECbis documents. [***]

Sorry to be an aspiring documentation-lawyer, but I presume what you
mean is that
(a) we should be developing a draft documentation which,
    if things run to completition will form a stand-alone set of documents
    which can be read as as update for the existing DNSSECbis protocol
    (i.e. that the two instances of the word "documentats" above should
    be "protocol"); and not
(b) that we are going to be doing work now which will result is us asking
    the IESG to change the DNSSECbis documents themselves prior to further
    advance down the standards track.

I would be worried if you did in fact mean (b) as I thought the entire
purpose of sending DNSSECbis off to the IESG although quite a few people
think it is far from perfect was so that further development would NOT
disrupt code development deployment.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Nov 2004 02:14:39 +1100

> IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion

	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: Roy Arends <[email-masked]>
Date: Thu, 11 Nov 2004 16:42:47 +0100 (CET)

On Fri, 12 Nov 2004, Mark Andrews wrote:

> 	to implement other online signing solutions.

Yes. So we can focus on nsec++. Online signing is not really optimal for
high load servers.

>       To get rid

Not really. This can be solved using CNAME for these extremely long names.
If you're referring to wildcards, I see the problem. Wildcard proofs using
NSEC++ may have multiple NSEC++'s in contrast with current NSEC where
there is a maximum of two.

> 	a second solution will be implemented.

No worries. Online signing is not an optimal solution. NSEC++ is not an
optimal solution as well. We might need both.

I do think that the larger TLD's might have a problem with dynamic
signing, due to several critical deployment issues, like an online key,
high response cost due to the crypto, key management between the
authoritative servers.

Typically, these larger TLD's do not have zones with very long, multiple
labels. In general TLD's have just single label deep delegations, so the
wildcard problem of > 2 NSEC++ does not apply.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Nov 2004 15:32:23 +0000

> 	of enumeneration in deep zones online signing appears to

As I pointed out yesterday, deep zones are only an issue with hashed 
NSEC if you consider the hashes to be names. Clearly this is the 
simplest solution, but, equally clearly, it is not the only one.

> 	a second solution will be implemented.

Given that there are several TLDs (and probably others) that won't 
deploy online keys, nor NSEC, I think you're wrong. But there's little 
point debating it. It'll either happen, or it won't.

Cheers,

Ben.

---

From: Rob Austein <[email-masked]>
Date: Thu, 11 Nov 2004 11:09:54 -0500

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

Um, no, at worst it means that when you synthesize an NSEC RR you also
have to synthesize something else, eg, a NULL RR.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 11 Nov 2004 16:56:49 +0000

> have to synthesize something else, eg, a NULL RR.

Nope don't think so - that changes wildcard behaviour.

I think that's even trivially exploitable, EG

$ORIGIN example.com

foo	IN	MX	mail-1.evilempire.com
*	IN	MX	mail-2.goodempire.com

Two users (Evil Ed, and User Ursula), share the same caching resolver.

Ursula wants to send mail to [email-masked]

Ed works out P(fred.example.com), S(fred.example.com), and queries for them
and for fred.example.com. example.com's nameserver returns an NSEC record
that mentions fred.example.com, and by your assumption synthesizes not
only the NSEC record but also a NULL RR, for fred.example.com. The NULL
RR is then cached by the caching nameserver.

This means Ursula's mail will NOT go to mail-2.goodempire.com, it will
either bounce (as an MX lookup will yield the NULL record), or possibly
go to the mail-1.evilempire.com.

Alex

---

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

--On 11 November 2004 13:55 -0500 "Ólafur Gudmundsson/DNSEXT co-chair" 
<[email-masked]> wrote:

> DNSSECbis documents are set in stone.
>
> The WG can issue NEW documents that clearly, coherently and safely
> specify changes in DNSSECbis protocol.

Thanks :-) (& I agree).

Alex

---

From: Rob Austein <[email-masked]>
Date: Thu, 11 Nov 2004 14:29:04 -0500

> Nope don't think so - that changes wildcard behaviour.

In what way does the existance of a synthetic NULL RRset change the
wildcard behavior compared to the behavior if only the synthetic NSEC
were present?  At least one of us is confused.

> Ed works out P(fred.example.com), S(fred.example.com), and queries for them

Queries with what QTYPE?

> RR is then cached by the caching nameserver.

Given suitable definitions of the P() and S() functions and a suitable
choice of RR type (something that is very unlikely to occur in normal
use, eg, NULL), the name server in the above scenario has several
hints that something evil is going on, and might choose to return
RCODE 5 (refused) rather than participating in the attack. :)

If for some reason it seems reasonable to return a synthetic NULL RR
in such a case (unlikely) it should probably have a TTL of zero.

In practice, the only real difference between this and the epsilon
solution as already described is that the bit corresponding to the
NULL RR type would be turned on in the NSEC bitvector.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 11 Nov 2004 20:47:44 +0000

> were present?  At least one of us is confused.

Yes.

I am assuming that the reason for the assumption Simon Josefsson mentioned:
under section 2.3 of protocol-09:

is that NOT doing so would require a change to wildcard behaviour,
and thus that in order to support epsilon NSECs, wildcard behaviour
would be changed so presence of an NSEC record "only" would not
"count" for the purposes of determining whether a wild-card was
applicable. If this is the case (i.e. if the appropriate change
is made to the wildcard treatment algorithm), then the restrictions
in 2.3 can be lifted.

However, if NO change to the wildcard processing stuff is made,
then as you point out they are equivalent, and (as far as I can
see) NSEC epsilons break wildcards. I seem to remember greater
minds than mine pointed this out at the time when we were considering
NSEC 'white lies' which is why the requirement in section 2.3 never
got removed at the time (because we didn't want to fiddle with
wildcard processing at that late stage).

The reason for the breakage is quite simple: Under NSEC epsilon,
every label must have an associated record returned on a query -
either it "really" exists (in which case by definition there is
a record), or it "really" does not (in which case by assumption - NSEC
epilson) there is an epsilon record pointing to the records successor.
Under such circumstances, the wildcard record is never the closest
encloser of anything (as the closest encloser is either an epsilon
NSEC or a real record).

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.

>> Ed works out P(fred.example.com), S(fred.example.com), and queries for

Not sure it particularly matters, but let's say ANY.

> RCODE 5 (refused) rather than participating in the attack. :)

How does that work algorithmically? I can only see heuristic solutions
to this, and it's a reasonable attack vector as far as I can see,
with potentially disastrous results.

If you are trying to change the use of NULL above in wildcard processing,
you might as well just change the wording and the wildcard algorithm for
NSEC instead and drop 2.3. NULL is actually USEFUL to indicate an
exception to a wildcard, as someone (Ed Lewis I think) pointed out to
me here not so long ago.

> NULL RR type would be turned on in the NSEC bitvector.

Why not just except NSECs from the wildcard algorithm, and drop the
text in 2.3? That's useful for both NSEC epsilon and NSEC' hashes.

Alex

---

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.

> 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: Paul Vixie <[email-masked]>
Date: Fri, 12 Nov 2004 01:00:47 +0000

> > ... 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.
> 
> prevents a caching resolver relying on a cached NSEC to fail to match
> an otherwise closest enclosing wildcard?

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

> break wildcards) - IE I don't think this /is/ a hole.

nope.  it was an oversight.  at least two editors admitted this to me in
person when i said "hey wait, we can't ship this to the iesg without
relaxing the parts that proscribe synthetic epsilon-named nsec rr's" but
the second of the two was able to explain how, actually, we could and must.

---

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

> (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: Paul Vixie <[email-masked]>
Date: Fri, 12 Nov 2004 17:34:37 +0000

> OK. Let me simplify a bit, drop the caching nameservers:
> 
> Take a zone example.com:
> *		MX	foo
> bar		MX	baz
> dummy		NULL
> dummy2	TXT	"fred"
> 
> 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.

> or the whole epsilon NSEC stuff doesn't work

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.

each of queries (1), (2), and (3) will produce the same NSEC result, but
with different RRtypes claimed at the ownername.  which is another very fine
reason why client-side negative caching based on previously cached NSEC RRs
won't work, and thus i renew my claim that wildcarding should be done on the
client side rather than the server side.  (but that's a different windmill.)

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

i don't know why you'd ever synthesize a NULL RR.  i don't like NULL RRs at
all, but in your example you made the NULL RR a real RR, not a synthetic one.
therefore query (4) would get a NOERROR/NODATA reply and the wildcard would
not be part of the choice of what to return -- because the qname actually
does exist.

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

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?

---

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

Paul,

>> *		MX	10	foo
>> bar		MX	10	baz
>> www		IN	A 	1.1.1.1
>> zzz		IN	A	2.2.2.2

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

...
> 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: Paul Vixie <[email-masked]>
Date: Sat, 13 Nov 2004 20:43:51 +0000

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

> ... 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.  we REALLY needed slabs before
security, to keep all the security metadata completely out of the dns world
view.  if you want to define NSEC2/NSEC3/whatever as having no effect on the
wildcard search algorythm, you'll have to do so explicitly, and carefully.

> Perhaps I'm making some mistake here.

your thinking on this topic is very creative.  i'm only able to fault you
on matters of terminology and for occasionally forgetting which constraints
will be in effect under which circumstances.  please do continue.

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

i don't think rob intended his offhand mention of NULL RRs to be given as
much scrutiny as you have done.  if it's not a helpful approach, abandon it.

---

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:

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

---

From: Paul Vixie <[email-masked]>
Date: Sun, 14 Nov 2004 20:02:36 +0000

> there is no reason to doubt you,  ...

every extension to every protocol relies on creative interpretation of
what were previously undefined or illegal symbol patterns.  EDNS depends
on ADCOUNT>0 in initiatorgrams (queries, updates, etc), which was not a
legal pattern in DNS.  once you've figured out a way to signal something
that will only be visible and valid to participants who understand it,
you've got your loophole.  everything after that is just whiteboarding.

>                             ...  then your assertion works because

now you're getting into the spirit of this thing.  welcome to the dark side.

what you have to define is how the authority servers will act.  given dns's
insane notion of authority-side-synthesis for wildcards, you just have to
make sure that the synthesis of wildcards and the sythesis of NSECs are done
in a way that queriers see what you want them to see.  it will require that
all authority servers for a given zone understand the same zone semantics,
but DNSSEC-bis also has this requirement, so extending it to cover synthetic
NSEC (and later, DNSSEC-ter) is completely reasonable.  you may have to add
some kind of format versioning, so that old-semantics authority servers will
refuse to load and serve new-semantics zones.  (we didn't do this in
DNSSEC-bis, and a lot of master/slave relationships are going to become
stressful as a result.)

> matters to we think) is carried out on the authoritative server.

yup.  being able to take advantage of the authority-side wildcard synthesis
insanity is a wonderful benefit after all the pain and cost that's been paid
by DNSSEC for said insanity up until now.

yes.

yes.

yes.

> the wildcard search algorithm to remove hashed NSEC' records is not

right.

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

also, it's too late.  this is one of many ideas that might have improved
DNSSEC-bis but would have added more years to its schedule, so while we
will miss the functionality, we will not be sorry we shipped without it.

> through dark holes and colliding in the middle]

the DNSSEC-bis documents overspecify a number of things, including this,
and i expect they will be edited to be more minimal before they can reach
the next bus-stop on the standards track.

---

From: David Fort <[email-masked]>
Date: Mon, 15 Nov 2004 11:13:08 +0100

>   not the owner name of any RRset before the zone was signed.
[...]
Correct me if i'm wrong, but the current NSEC allows to prove that a 
domain is an Empty Non-Terminal domain. The dynamic NSEC proposed in 
that draft prevent from doing this. Isn't that a problem ?

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33