Re: DNSEXT WGLC: DNS Threats

[Rob Austein <[e-mail]>]

I've incorporated the last call comments so far, and just did an
ID-nits.html pass of my own.  diff of nroff changes attached below,
but for a good time check out:

  http://www.hactrn.net/ietf/dns/threats/changes-from-02-to-current.html

which I generated using Bill Fenner's nifty htmlwdiff script.

Note that a few of the changes take the form of explicitly stating
that certain topics are beyond the scope of the current document
rather than just not having been written yet.  I think that this is
consistant with what the WG is telling me (namely, that it's time to
ship this puppy, and handle future work in future documents).

Last, I'd appreciate it if somebody could look over the list of
references to see if I got the Normative/Informative split right.
There's plenty of room left in the Acknowledgements section :).

Thanks!

--Rob

diff -u -B -b -r1.18 -r1.19
--- draft-ietf-dnsext-dns-threats.ms	4 Nov 2002 05:34:55 -0000	1.18
+++ draft-ietf-dnsext-dns-threats.ms	26 Mar 2003 19:10:35 -0000	1.19
@@ -1,7 +1,7 @@
-.\" $Id: draft-ietf-dnsext-dns-threats.ms,v 1.18 2002/11/04 05:34:55 sra Exp $
+.\" $Id: draft-ietf-dnsext-dns-threats.ms,v 1.19 2003/03/26 19:10:35 sra Exp $
 .\"
 .\" %% draft_name   ::= draft-ietf-dnsext-dns-threats
-.\" %% draft_number ::= 02
+.\" %% draft_number ::= 03
 .\" %% author_foot  ::= Atkins & Austein
 .\" %% author       ::= D. Atkins
 .\" %% author       ::= IHTFP Consulting
@@ -97,7 +97,7 @@
 
 While a number of detail decisions were yet to be made (and in some
 cases remade after implementation experience) over the subsequent
-eight years, the basic model and design goals have remained fixed.
+decade, the basic model and design goals have remained fixed.
 
 Nowhere, however, does any of the DNSSEC work attempt to specify in
 any detail the sorts of attacks against which DNSSEC is intended to
@@ -107,8 +107,8 @@
 until 1995, for reasons that Bellovin explained in the paper's
 epilogue [Bellovin95].
 
-While it may seem a bit strange to publish the threat analysis eight
-years after starting work on the protocol designed to defend against
+While it may seem a bit strange to publish the threat analysis a
+decade after starting work on the protocol designed to defend against
 it, that is nevertheless what this note attempts to do.  Better late
 than never.
 
@@ -117,12 +117,12 @@
 
 For purposes of discussion, this note uses the term "DNSSEC" to refer
 to the core hierarchical public key and signature mechanism specified
-in the DNSSEC documents, and refer to TKEY and TSIG as separate
+in the DNSSEC documents, and refers to TKEY and TSIG as separate
 mechanisms, even though TKEY and TSIG are also part of the larger
 problem of "securing DNS" and thus are often considered part of the
 overall set of "DNS security extensions".  This is an arbitrary
 distinction that in part reflects the way in which the protocol has
-evolved (introduction of a putatively simpler transaction model
+evolved (introduction of a putatively simpler transaction model for
 certain operations), and perhaps should be changed in a future
 revision of this note.
 
@@ -154,7 +154,7 @@
 even chose to return the correct result in the answer section of a
 reply message while using other parts of the message to set the stage
 for something more complicated, for example, a name-based attack
-(q.v., below).
+(see below).
 
 While it certainly would be possible to sign DNS messages using TSIG
 or IPsec, or even to encrypt them using IPsec, this would not be a
@@ -186,7 +186,7 @@
 .in 5
 
 .ti 3
-- Perform all all of the DNSSEC signature checking on its own,
+- Perform all of the DNSSEC signature checking on its own,
 
 .ti 3
 - Use TSIG (or some equivalent mechanism) to insure the integrity of
@@ -260,8 +260,8 @@
 
 .ti 3
 - Victim issues a query, perhaps at the instigation of the attacker or
-some third party; in some the query itself may be unrelated to the
-name under attack (ie, the attacker is just using this query as a
+some third party; in some cases the query itself may be unrelated to the
+name under attack (that is, the attacker is just using this query as a
 means to inject false information about some other name).
 
 .ti 3
@@ -392,7 +392,7 @@
 in some cases, even the immediate failure of a missing RR might be
 considered a problem.  The question remains: how serious is this
 threat?  Clearly the threat does exist; general paranoia says that
-some day it'll be on the front page of the New York Times, even if we
+some day it'll be on the front page of some major newspaper, even if we
 cannot conceive of a plausible scenario involving this attack today.
 This implies that some mitigation of this risk is required.
 
@@ -514,9 +514,10 @@
 
 .ti 0
 .ne 4
-4.  Other issues
+4.  Topics for Future Work
 
-[Odds and ends that don't yet fit anywhere else, to be revised...]
+This section lists a few subjects not covered above which probably
+need additional study, additional mechanisms, or both.
 
 .ti 0
 .ne 4
@@ -526,7 +527,7 @@
 the boundaries of the DNS protocol itself, since those are the
 problems against (some of) which DNSSEC was intended to protect.
 There are, however, other potential problems at the boundaries where
-DNS interacts with other protocols.  This topic needs further study.
+DNS interacts with other protocols.
 
 .ti 0
 .ne 4
@@ -576,8 +577,8 @@
 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.
+Scaling properties of the key management problem here are a particular
+concern that needs more study.
 
 .ti 0
 .ne 4
@@ -619,13 +620,13 @@
 
 This entire document is about security considerations of the DNS.  The
 authors believe that deploying DNSSEC will help to address some, but
-not all, of the known threats to with DNS.
+not all, of the known threats to the DNS.
 
 .ti 0
 .ne 4
 IANA Considerations
 
-None known.
+None.
 
 .ti 0
 .ne 4
@@ -634,54 +635,25 @@
 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
+Jaap Akkerhuis,
 Steve Bellovin,
 Dan Bernstein,
 Randy Bush,
 Olafur Gudmundsson,
+Rip Loomis,
 Allison Mankin,
+Paul Mockapetris,
+Mans Nilsson,
 Paul Vixie,
+Xunhua Wang,
 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.
-
 .in 8
 .ti 0
 .ne 4
-References
-
-.ti 3
-[Bellovin95] 
-Bellovin, S.,
-"Using the Domain Name System for System Break-Ins",
-Proceedings of the Fifth Usenix Unix Security Symposium,
-June 1995.
-
-.ti 3
-.ne 2
-[Galvin93] Design team meeting summary message posted to
[e-mail] mailing list by Jim Galvin on 19 November 1993.
-
-.ti 3
-.ne 2
-[Schuba93]
-Schuba, C.,
-"Addressing Weaknesses in the Domain Name System Protocol",
-Master's thesis, 
-Purdue University Department of Computer Sciences, 
-August 1993.
-
-.ti 3
-.ne 2
-[Vixie95]
-Vixie, P,
-"DNS and BIND Security Issues",
-Proceedings of the Fifth Usenix Unix Security Symposium,
-June 1995.
+Normative References
 
 .ti 3
 .ne 2
@@ -710,7 +682,7 @@
 .ti 3
 .ne 2
 [DNS-CLARIFY]
-Elz, R., and Bush, R.,
+Elz, R., and R. Bush, 
 "Clarifications to the DNS Specification"
 RFC 2181,
 July 1997.
@@ -742,7 +714,7 @@
 .ti 3
 .ne 2
 [TSIG]
-Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B.,
+Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 
 "Secret Key Transaction Authentication for DNS (TSIG)"
 RFC 2845,
 May 2000.
@@ -779,12 +751,46 @@
 RFC 3090,
 March 2001.
 
+.in 8
+.ti 0
+.ne 4
+Informative References
+
+.ti 3
+[Bellovin95] 
+Bellovin, S.,
+"Using the Domain Name System for System Break-Ins",
+Proceedings of the Fifth Usenix Unix Security Symposium,
+June 1995.
+
+.ti 3
+.ne 2
+[Galvin93] Design team meeting summary message posted to
[e-mail] mailing list by Jim Galvin on 19 November 1993.
+
+.ti 3
+.ne 2
+[Schuba93]
+Schuba, C.,
+"Addressing Weaknesses in the Domain Name System Protocol",
+Master's thesis, 
+Purdue University Department of Computer Sciences, 
+August 1993.
+
+.ti 3
+.ne 2
+[Vixie95]
+Vixie, P,
+"DNS and BIND Security Issues",
+Proceedings of the Fifth Usenix Unix Security Symposium,
+June 1995.
+
 .ti 3
 .ne 2
 [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),
+work in progress (draft-iab-sec-cons-03.txt),
 October 2002.
 
 .in 6
@@ -806,7 +812,46 @@
 Rob Austein
 
 Email: [e-mail]
+
 .fi
+.in 3
+.ti 0
+.ne 4
+Full Copyright Statement
+
+Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works.  However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+.ti 0
+.ne 4
+Acknowledgement
+
+Funding for the RFC Editor function is currently provided by the
+Internet Society.
+
 .\"
 .\" Local Variables:
 .\" mode:nroff