Subject: new version of draft-ietf-dnsext-dns-threats

From: Rob Austein <[email-masked]>
Date: Mon, 04 Nov 2002 01:40:18 -0500

A new version of draft-ietf-dnsext-dns-threats is in the I-D queue to
replace the expired version.  Not a lot of change from the expired
version (less than I had intended, ran out of time).  For the record:
my co-author had no input on these changes, they were all done by me,
writing in haste to capture what I could of several recent
discussions, so please don't blame Derek for any errors or omissions.

Diff of the non-cosmetic stuff attached, for those who have read the
previous versions.

--- draft-ietf-dnsext-dns-threats-01.txt	Mon Nov  4 01:30:00 2002
+++ draft-ietf-dnsext-dns-threats-02.txt	Mon Nov  4 01:30:00 2002
@@ -361,6 +361,39 @@
    if we cannot conceive of a plausible scenario involving this attack
    today.  This implies that some mitigation of this risk is required.
 
+   Note that it's necessary to prove the non-existance of applicable
+   wildcard RRs as part of the authenticated denial mechanism, and that,
+   in a zone that is more than one label deep, such a proof may require
+   proving the non-existance of multiple discrete sets of wildcard RRs.
+
+2.7.  Wildcards
+
+   Much discussion has taken place over whether and how to provide data
+   integrity and data origin authentication for "wildcard" DNS names.
+   Conceptually, RRs with wildcard names are patterns for synthesizing
+   RRs on the fly according to the matching rules described in section
+   4.3.2 of RFC 1034.  While the rules that control the behavior of
+   wildcard names have a few quirks that can make them a trap for the
+   unwary zone administrator, it's clear that a number of sites make
+   heavy use of wildcard RRs, particularly wildcard MX RRs.
+
+   In order to provide the desired services for wildcard RRs, we need to
+   prove two things:
+
+   - We need to prove the existance of the wildcard RR itself (that is,
+     we need to prove that the synthesis rule exists), and
+
+   - We need to prove the non-existance of any RRs which, if they
+     existed, would make the wildcard RR irrelevant according to the
+     synthesis rules the way in which wildcards are used (that is, we
+     need to prove that the synthesis rule is applicable).
+
+   Note that this makes the wildcard proof mechanism dependent upon the
+   authenticated denial mechanism described in the previous section.
+
+   DNSSEC does include mechanisms by which it is possible to furnish
+   wildcard proofs along the lines described above.
+
 3.  Weaknesses of DNSSEC
 
    DNSSEC has some problems of its own:
@@ -414,6 +447,20 @@
      generating signatures whose validity period does not match what the
      signer intended.
 
+   - The mechanism for wildcard proofs in DNSSEC is fairly painful.  At
+     various times there have been questions as to whether the proof
+     mechanism is completely airtight and whether it would be worthwhile
+     to optimize the wildcard proof mechanism for the common case in
+     which wildcards do not exist, but the main problem is just the
+     inherent complexity of the wildcard mechanism itself.  This
+     complexity probably makes the code for generating and checking
+     wildcard proofs somewhat fragile, but since the alternative of
+     giving up wildcards entirely is not practical due to widespread
+     use, we are going to have to live with wildcards, and the question
+     just becomes one of whether or not the proposed optimizations would
+     make DNSSEC's wildcard proof mechanisms more or less fragile.
+
+
 4.  Other issues
 
    [Odds and ends that don't yet fit anywhere else, to be revised...]
@@ -465,12 +512,37 @@
    to multiple entities, each of whom may require different kinds of
    access.  For example, Alice may need to be able to add new nodes to
    the zone or change existing nodes, but not remove them; Bob may need
-   to be able to remove zones but not add them; Charlie may need to be
+   to be able to remove zones but not add them; Carol may need to be
    able to add, remove, or modify nodes, but only A records.
 
    NOTE: Scaling properties of the key management problem here is a
    particular concern that needs more study.
 
+4.3.  Securing DNS Zone Replication
+
+   As discussed in previous sections, DNSSEC per se attempts to provide
+   data integrity and data origin authentication services on top of the
+   normal DNS query protocol.  Using the terminology discussed in [SEC-
+   CONS], DNSSEC provides "object security" for the normal DNS query
+   protocol.  For purposes of replicating entire DNS zones, however,
+   DNSSEC does not provide object security, because zones include
+   unsigned NS RRs and glue at delegation points.  Use of TSIG to
+   protect zone transfer (AXFR or IXFR) operations provides "channel
+   security", but still does not provide object security for complete
+   zones, so the trust relationships involved in zone transfer are still
+   very much a hop-by-hop matter of name server operators trusting other
+   name server operators, rather than an end-to-end matter of name
+   server operators trusting zone administrators.
+
+   Zone object security was not an explicit design goal of DNSSEC, so
+   failure to provide this service should not be a surprise.
+   Nevertheless, there are some zone replication scenarios for which
+   this would be a very useful additional service, so this seems like a
+   useful area for future work.  In theory it should not be difficult to
+   zone object security as a backwards compatible enhancement to the
+   existing DNSSEC model, but the DNSEXT WG has not yet discussed either
+   the desirability of or the requirements for such an enhancement.
+
 5.  Conclusion
 
    Based on the above analysis, the DNSSEC extensions do appear to solve
@@ -488,12 +560,18 @@
 
 Acknowledgments
 
-   This note is based both previous published works by others and on on
-   a number of discussions both public and private over a period of many
+   This note is based both previous published works by others and on a
+   number of discussions both public and private over a period of many
    years, but particular thanks go to Steve Bellovin, Dan Bernstein,
-   Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and our
-   libel lawyers at the firm of Dewey, Chetham, & Howe, none of whom are
-   responsible for what the authors did with their ideas.
+   Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and any
+   other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups
+   whose names and contributions the authors have forgotten, none of
+   whom are responsible for what the authors did with their ideas.
+
+   The authors would also like to thank Paul Mockapetris and Xunhua
+   Wang, both of whom sent useful information to the authors, about
+   which the authors have, as yet, done absolutely nothing.  We were
+   listening, really, we just ran out of time before the draft deadline.
 
 References
 
@@ -548,6 +626,11 @@
    [DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification
         on Zone Status" RFC 3090, March 2001.
 
+   [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture
+        Board, "Guidelines for Writing RFC Text on Security
+        Considerations", work in progress (draft-iab-sec-cons-01.txt),
+        October 2002.
+
 Author's addresses:
 
       Derek Atkins