Subject: Re: On dynamic NSEC

From: Alex Bligh <[email-masked]>
Date: Thu, 11 Nov 2004 13:10:45 +0000

--On 11 November 2004 13:04 +0100 Simon Josefsson <[email-masked]> wrote:

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

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

--
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: Ben Laurie <[email-masked]>
Date: Thu, 11 Nov 2004 14:31:03 +0000

Simon Josefsson wrote:
> 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
> 

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

Cheers,

Ben.

---

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