Dropping denial of existence of wildcard

["Olaf M. Kolkman" <olaf@ripe.net>]

The wildcard optimization draft was written under the assumption that
denial of existence of a match covered by a wildcard is needed. (see
2.7 of the dns-threats draft). As we are editing the
wildcard-optimization draft we would like to have feedback on the
following.
 
   Why not simplify the protocol and implementation by dropping denial of
   existence of wildcards?


We realize we stir the pot with this question so let us elaborate.
 
Having to denial the existence of a (closer) match to a wildcard
brings a lot of complications. It is not only computationally
expensive but also complex and error prone (The first implementations
did not do it correctly. We worry that without proper documentation of
the algorithm both servers and verifying resolvers will do things
wrong).


The threats model does not document why denial of existence of
wildcards is needed ("in order to provide the desired services" does
not specify 'desired').


What if we threw out a lot of complicated code and possible
troubleshooting headache at the cost of loosing the authenticated
denial of a (closer) matching wildcard? One would be vulnerable to
the following attack vectors:


  1. A NXDOMAIN could be spoofed for names for which a wildcard
     expansion is possible
 
  2. A match to a wildcard can be replaced with a less closer matching 
     wildcard.
 
 
In our opinion the second attack is the most worrying one; verifiable
data but wrong data is returned. On the other hand in most cases where
there are multiple wildcards in a zone it is because there is a name
in the zone that cancels the generic match and both wildcard point to
the same data.
 
 e.g
 
     example   MX   generic_mailhost
   *.example   MX   generic_mailhost
   a.example   MX   specific_mailhost
 *.a.example   MX   generic_mailhost
 
Besides if one wants to be secured that mail to a given host is being
delivered than one can always configure that hosts MX record. It's
more trivial to write a tool for that than having to troubleshoot why
one of your clients get a SERVFAIL on one of your signed zones.
 
The first kind of attack is a DOS type of attack. It can also be
circumvented by hard configuring the mailhosts for your important
services. 
 
(We use MX/mailhosts in our example but the arguments apply to general
usage)
 
So far the possible attack vectors.
 
We would like to hear the WG's opinion on the idea to drop denial of
existence of wildcards. If we do not drop the denial of existence I
think it is vital for proper deployment of DNSSEC that somebody publishes
the algorithm to deliver and verify proof of non-existence of (closer)
matching wildcards. Preferably with a correctness proof of that algorithm.

 
 Olaf Kolkman and Johan Ihren.




--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>