Subject: Re: thesaurus attack

From: Robert Elz <[email-masked]>
Date: Sat, 11 Sep 2004 06:01:14 +0700

Date:        Sat, 11 Sep 2004 00:14:08 +0200
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | OK, but then for the sake of clarity the draft should mention this case
  | explicitly, e.g.:

Perhaps, I'm not sure it is really important enough to anything to matter.
Who really cares after all?   The resolver can't (normally) tell (either
whether the name is terminal, or unless it was an ANY query, whether it is
actually empty).   For DNSSEC purposes (with me being no expert on that stuff)
as I understand it, the proofs need to involve the '*' record explicitly,
as there's no way to actually sign the fabricated RR returned (or not
without on-line keys) - so this is already an odd special case.

  | Empty Terminals

But if this is to be included ...

  |   Although there is a NULL RR type specified in RFC 1035,
  |   its purpose is left open.

That sentence doesn't belong, not that it is wrong, it is simply
irrelevant - you might just as well mention that the HINFO RR type
exists (or any other arbitrary one).   The NULL RR is an RR, just
like any other (however undefined its purpose is...)

kre

--
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: Mon, 13 Sep 2004 16:38:55 -0400

>without on-line keys) - so this is already an odd special case.

On the first cut, authenticated denial ("DNSSEC purposes") doesn't 
require proof that there is no "*"/"wild card"/"source of synthesis," 
all that is needed is to prove that there are no matching RRsets to 
the query.

The choice is to 1) customize the reply *message* to the query or 2) 
prove by showing that at each step of the 4.3.2 algorithm that name 
matches fail.  Of course 1 means on-line keys, which is something the 
design of DNSSEC has tried hard to avoid.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: Robert Elz <[email-masked]>
Date: Tue, 14 Sep 2004 04:30:38 +0700

Date:        Mon, 13 Sep 2004 16:38:55 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a0602040bbd6bb479d3e3@[192.136.136.102]>

  | >as I understand it, the proofs need to involve the '*' record explicitly,
  | 
  | On the first cut, authenticated denial ("DNSSEC purposes") doesn't 
  | require proof that there is no "*"/"wild card"/"source of synthesis," 

I'll reply to other messages later, but in the above, I wasn't talking
about denial at all, but proof of legitimacy of a RR generated (synthesised)
from a wildcard RR.

That is, I lookup foobar.example. MX, which doesn't exist, but example.
contains *.example. MX 10 whatever.   That means the answer I get is
foobar.example. MX 10 whatever.   That RR needs to be authenticated, but
there cannot be a SIG for it (or not without on-line keys).

Without having attempted to find the actual answer to this, I'd assume that
what is required is the *.example. record itself, its SIG, plus proof that
foobar.example. doesn't exist - all being used as positive proof that the
MX record in the answer section is indeed what it is supposed to be.

kre