Subject: Wildcards and Opt-In

From: Daniel Massey <[email-masked]>
Date: Wed, 30 Jan 2002 10:09:20 -0500

Hi,

The use of wildcards in DNSSEC is somewhat awkward at best and
I think it becomes a severe problem if Opt-In is used.

Suppose you have a entry such as:
  *.edu. MX 10 mail.junk.edu
  SIG by edu.

Now suppose a query for nge.isi.edu MX returns:
   nge.isi.edu.  MX 10 mail.junk.edu
   SIG by edu. (with label = 1)

Is this a valid answer or a response from an attacker?
  if isi.edu does NOT exist, then this is valid use of 
    wildcards and should be believed.
  if isi.edu does exist, then the wildcard should not apply
    and perhaps an attacker is trying to prevent me from
    learning the real nge.isi.edu MX record by replaying
    the edu. wildcard entry.  

With opt-in, how can I distinguish a valid, signed response
from an attacker's intentionally incorrect replay of wildcard?

Perhaps we should rethink the use of wildcards or at least
rethink how wildcards would interact with opt-in.

Dan

PS The DNSSEC use of wildcards is not currently implemented  
   but is described in RFC 2535 sections:
     section 4.1.3 (labels field in the SIG RR)
     section 5.3 (NXT and proving no wildcard matches) 
     and some minor stuff in 8.1 and 8.3

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Jan 2002 10:47:46 -0500

When we discussed wildcards a couple of years ago, we noted the need to
send along NXT's to prove that the use of the wildard was warrented.  E.g.,
if nge.isi.edu, then the proper response would be:

    nge.isi.edu.  MX 10 mail.junk.edu
    SIG by edu. (with label = 1)
    NXT showing no nge.isi.edu
    SIG (NXT) by edu.

I don't know if the need for the NXT has been maintained in the document
history since then, nor in the code.

The short answer to your question (how can I distinguish) is that the
proper NXT or NXTs are needed in the answer.

>the word 'unsubscribe' in a single line as the message text body.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: Roy Arends <[email-masked]>
Date: Wed, 30 Jan 2002 23:32:49 +0100 (CET)

> from an attacker's intentionally incorrect replay of wildcard?

Okay, lets look at these entries:

("l=x" where x is the value of the labels field in the signature)

edu.    SOA
edu.    SIG SOA (l=1)
edu.    NS a.edu.
edu.    SIG NS  (l=1)
edu.    MX 10 a.edu.
edu.    SIG MX  (l=1)
edu.    KEY ...
edu.    SIG KEY (l=1)
edu.    NXT *.edu. SOA NS MX SIG NXT
edu.    SIG NXT (l=1)

*.edu. MX 10 mail.junk.edu.
*.edu. SIG MX  (l=1)
*.edu. NXT a.edu. MX SIG NXT
*.edu. SIG NXT (l=1)

a.edu.  A 10.0.0.1
a.edu.  SIG A   (l=2)
a.edu.  NXT mail.junk.edu. A SIG NXT
a.edu.  SIG NXT (l=2)

mail.junk.edu. A 10.0.0.2
mail.junk.edu. SIG A   (l=3)
mail.junk.edu. NXT edu. A SIG NXT
mail.junk.edu. SIG NXT (l=3)

Okidook, now look at some responses

query(nge.isi.edu., MX):

response:
nge.isi.edu. MX  10 mail.junk.edu.      ;expanded wildcard
nge.isi.edu. SIG MX  (l=1)              ;expanded wildcard since l=1
a.edu. NXT mail.junk.edu. A SIG NXT     ;proof of not a more specific name
a.edu. SIG NXT (l=2)                    ;exists

This whole thing assumes 2535, not opt-in.
-------------------------
Now with opt-in:

Assume in the above the following:

a.edu.  A 10.0.0.1
a.edu.  SIG A   (l=2)
a.edu.  NXT mail.junk.edu. A SIG        ;no NXT bit -> OPT-IN
a.edu.  SIG NXT (l=2)

isi.edu NS

query(nge.isi.edu., MX):

forged, but valid response:

nge.isi.edu. MX 10 mail.junk.edu.     ;expanded wildcard
nge.isi.edu. SIG MX  (l=1)            ;expanded wildcard since l=1
a.edu. NXT mail.junk.edu. A SIG       ;proof of not a more specific SIGNED name
a.edu. SIG NXT (l=2)                  ;  (i.e. no signed isi.edu delegation)

(this is forged, since the server would have given an unsigned referral)

What does the above response mean:

1) The resolver is able to verify that the signature over
   nge.isi.edu. MX is really an expanded wildcard.

2) The resolver is able to verify that there does not exist a more
   specific SIGNED name.

Conclusion:

Since the isi.edu. has chosen not to be signed, a malicious entity can
forge everything under and including isi.edu. No news here.

To avoid all of the above: its your zone, your choice, sign everything or
leave wildcards unsigned, or better, avoid using them.

Roy Arends
Nominum

---

From: Mark Kosters <[email-masked]>
Date: Wed, 30 Jan 2002 18:29:56 -0500

> leave wildcards unsigned, or better, avoid using them.

What Roy said. Plus, in testing that I was doing to make sure that I'm
not missing something, dnssec-signzone (9.2.0) comes back saying:

dnssec-signzone: warning: BIND 9 doesn't properly handle wildcards in secure 
zones:
        - wildcard nonexistence proof is not generated by the server
        - wildcard nonexistence proof is not required by the resolver
dnssec-signzone: warning: wildcard name seen: *.edu

Mark

-- 

Mark Kosters             [email-masked]       Verisign Applied Research

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jan 2002 20:06:14 -0800

i suggest that the questions we might be asking, in kind of priority order,
are as follows:

  o are the semantics of wildcards well defined in the presence of dnssec
    (or vice versa)?  does 2535 really cover it?  if not, do we think they
    can be?

  o does it really require the complexity of 2535?  if so, is it worth
    it?

  o does the possibility of wildcards change/weaken security, even if a
    signed zone does not use them?

  o does the presense of wildcards in a signed zone change/weaken the
    security of that zone?

  o Does the presence of a wild card in a signed zone change/weaken the
    security of delegations from that zone?

  o do wildcards in a signed zone interact badly with other parts of the
    standard or with other work we are contemplating now.

randy

---

From: Bob Halley <[email-masked]>
Date: 30 Jan 2002 21:05:18 -0800

>     (or vice versa)?  does 2535 really cover it?  if not, do we think they

The semantics are well defined.

>   o does it really require the complexity of 2535?  if so, is it worth

The NXT proof specified by RFC 2535 is required, since otherwise a
wildcard can be used to obscure more specific secure data.

The other complexity (e.g. the label count number) is required
otherwise verifiable signatures cannot be generated.

>     standard or with other work we are contemplating now.

Wildcards are a pain in the butt, and I often dislike them, but they
can be made to work.

I think the answers to the above are all no.  The main issue with
wildcard proof has been the complexity of generating it and validating
it efficiently especially if binary labels are present.  The obvious
"try every possibility" algorithm seemed like a bad idea if you had to
do 100+ iterations of the algorithm due to long IPV6 binary labels.
Better algorithms which use more info from the NXT records are
possible (I think) but a little tricky.  If binary labels are going
away, this won't be a problem :).

/Bob

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: Bob Halley <[email-masked]>
Date: 30 Jan 2002 21:08:05 -0800

> Is this a valid answer or a response from an attacker?

It's invalid as a secure response because there is no NXT proof that
nge.isi.edu and isi.edu don't exist.  Responses from the secure
subzone must include all relevant proof.

Let's consider a few cases about isi.edu, and what a secure validator
would expect.  (The same kind of reasoning would also apply for
nge.isi.edu.)

        isi.edu. does not exist at all in the zone.

                In this case it doesn't exist in the secure subzone
                either, so there will be some NXT in the secure
                subzone which proves it doesn't exist.  A secure
                validator will expect this proof and not be fooled.
                If the NXT bit is set on the NXT records, the
                validator would know that isi.edu. is in the
                non-secure part of an opt-in zone if it exists at all.
                That's all you ever know with non-secure data, so
                there's no problem here.

        isi.edu. does exist, and is in the secure part of the zone.

                In this case no NXT proving its nonexistence will
                exist, and the attacker cannot forge a believable
                secure response because he will not have the required
                NXT proof.

        isi.edu. does exist, and is in the non-secure part of the zone.

                As far as validation goes, this case is the same as
                the first case.

Note that in all cases a secure validator can identify whether or not
isi.edu is in the secure part of the zone or not, and the required
nonexistence proof for secure wildcards will always be available.

> from an attacker's intentionally incorrect replay of wildcard?

The valid signed response would include the relevant NXT proof.

/Bob