Subject: opt-in and wildcards

From: David Blacka <[email-masked]>
Date: Thu, 19 Sep 2002 17:37:56 -0400

Ok, I've been thinking about the interactions between opt-in and
wildcards in dnssec.  I apologize if this is redundant.  I also
apologize for the rather long length.

So far the following questions have more or less been raised:

1) Do wildcard NXT proofs need to be returned with positive opt-in
answers (that is, when an opt-in server is returning a "opted-out"
insecure delegation)?

2) Should a signed wildcard record be able to trump an insecure
delegation when both are available to the resolver?

I am ignoring the thread talking about getting rid of wildcards in
DNSSEC altogether.

First, suppose the answer to question #1 is yes, wildcard proofs are
to be returned.  Then we might see a response like:

  Q:     foo.example A
  ANS: 
  AUTH:  foo.example NS <...>
         e           NXT g ... (opt-in)
         e           SIG NXT ...
         example     NXT a ... (no wildcard).
         example     SIG NXT ...
  ADD:   ...

which seems fine.  But, what happens when a wildcard actually exists?
Then maybe we would see a response like this:

  Q:     foo.example A
  AUTH:  foo.example NS <...>
         e           NXT g ... (opt-in)
         (proof the the wildcard exists)
	 foo.example A 1.1.1.1
         foo.example SIG A (labels = 1)

The resolver is presented both with a delegation and a wildcard.  This
leads us to question #2.

In this scenario, if the resolver were to believe the wildcard over
the delegation, essentially insecure delegations in opt-in zone would
simply not work because the wildcard would mask all the insecure
delegations.

So the answer to question #2 would seem to be No.

If the answer was yes, then I think we would be giving new power to
wildcard records that was never intended.

The reasoning above suggests that the answer to question #1 is also
No.  However, it is probably not sufficient to go by this reasoning
alone.

So considering question #1 more directly:

With opt-in, insecure delegations may be modified, added, or removed
within the insecure spans within the zone.  The current draft language
is 

   With Opt-In, a malicious entity is able to: insert, modify, or
   delete insecure delegation RRsets within a secured zone.

Because of this, a resolver cannot detect whether or not a particular
insecure delegation response was spoofed or not.  Since the delegation
might actually be real, the resolver really has no choice but to
believe that it is real.  The presence or absence of a matching
wildcard becomes not relevant, because the resolver cannot make a
decision based on that fact.

Looking at this (yet) another way, we can see that an attacker could
replace an insecure delegation with a wildcard expansion, thus
effective removing the delegation.  Of course, the attacker could
already have done that.  Also an attacker could replace a wildcard
expansion with a spoofed delegation (pointing wherever the attacker
wished).

This is not really a different security concern from the first form of
attack, but it does show that the language in the draft does not go
far enough.  I will point out that although wildcard records are
signed, their expanded names are not.  Perhaps the opt-in draft's
security consideration language should be more along the lines of:

  With Opt-In, a malicious entity is able to: insert, modify, or
  delete insecure delegation RRsets within a secured zone.  A
  malicious entity is also able to replay or delete wildcard
  expansions within insecure spans in the zone.

Or perhaps:

  With Opt-In, a malicious entity is able to insert, modify or remove
  RRsets within the insecure spans of a secured zone.  The RRsets are
  limited to insecure delegations and wildcard expansions.

So the answer to question #1 is No.

Opt-In does not change the fact that negative wildcard proofs are
needed in an NXDOMAIN response, just like non-opt-in.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

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