Threat Analysis of the Domain Name System (DNS)
RFC 3833

[Ballot comment]
Perhaps the discussion of MX records should note that a fake MX record could be used to divert mail to an enemy site.  Or maybe not, since mail that's sensitive should be encrypted anyway.

The claim that only RRs with names in the RDATA are vulnerable is, I think, incorrect.  A major cache contamination attack described described in [Bellovin95] inserted an A record to foil the cross-check on the name returned in an (enemy-generated) PTR record.  Admittedly, this only affects people who do name-based authentication, but I do think it should be mentioned.  (This is close to a DISCUSS, since it's an issue of technical accuracy, rather than style.)

My style when writing something like this would be to add citations to the first published description when describing individual attacks.  Your mileage may vary, and all of the important references are in the draft.

Comments from John Loughney, gen-ART reviewer:

This document looks good, I think that even though DNSSEC has been under development for a long time, capturing the Threat Analysis is a good thing.  I say ship it, I just have a few nit-picky comments.

1) Abstract:

        Among other drawbacks, this cart-before-the-horse situation

-> The 'cart-before-the-horse' phrase may not be appropriate for an abstact.

2) Section 1:

  - While some participants in the meeting were interested in
    protecting against disclosure of DNS data to unauthorized parties,
    the design team made an explicit decision that "DNS data is
    `public'", and ruled all threats of data disclosure explicitly out
    of scope for DNSSEC.

-> Change ` to ' character.

3) Section 2.1:

  Some of the simplest threats against DNS are various forms of packet
  interception: monkey-in-the-middle attacks,

-> Are 'monkey-in-the-middle attacks' the same as man-in-the-middle attacks?
  If so, perhaps revise.  If it is something else, perhaps a definition is needed.

4) Section 2.3, last paragraph:

  DNSSEC should provide a good defense against most (all?) variations

-> What is the meaning of 'most (all?)'?  Perhaps strike the (all?) or
  change to something like:

  DNSSEC should provide a good defense against most, if not all, variations

5) Update Copyright statement at the end of the document.

[Note]: '2003-03-06: This document has been before the IESG before; this
version addresses comments from smb, housley, and wijnen (from ops
directorate).
' added by Thomas Narten

2004-02-05:

From: Rob Austein
To: Thomas Narten , Olaf Kolkman ,
  =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?=
Cc: Derek Atkins
Date: Thu, 05 Feb 2004 12:14:57 -0500
Subject: Re: draft-ietf-dnsext-dns-threats-06
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)

new development: derek and i just received some last minute comments
from steve crocker.  i've incorporated the no-brainers (spelling,
etc), am chatting with him about the slightly more substantial ones.
no showstoppers, just suggestions for improvement.

i've updated the snapshot on www.hactrn.net.  more later, time
permitting.

[Note]: 'Sent comments to authors. Some minor questions/comments, have asked if they want to respin or just forward to IESG.' has been cleared by Thomas Narten