Re: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12

Matthijs Mekking <> Tue, 28 August 2012 09:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00E7B21F854D; Tue, 28 Aug 2012 02:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oLCOfUiBwgX7; Tue, 28 Aug 2012 02:10:01 -0700 (PDT)
Received: from ( [IPv6:2001:7b8:206:1::1]) by (Postfix) with ESMTP id 951F321F854B; Tue, 28 Aug 2012 02:10:00 -0700 (PDT)
Received: from [IPv6:2001:7b8:206:1:7dea:95c2:f2f9:298f] ([IPv6:2001:7b8:206:1:7dea:95c2:f2f9:298f]) (authenticated bits=0) by (8.14.5/8.14.4) with ESMTP id q7S99rlK027027 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 11:09:54 +0200 (CEST) (envelope-from
X-DKIM: OpenDKIM Filter v2.6.7 q7S99rlK027027
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1346144996; bh=i4KW6wIJMmnc2qRl4WGeOmOOu50L31Glu5av5QvtqA0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Ce9vtwZ/rsuTKiBDjdtYM65BbZTjbimXi1b5rbBDJYaO7SPJ8DjGW/74Gs7+Ru4Hr IqTgrvSTJQ7Upl4MFpj99MvOyx1hAlzC4CEhOw9MoD5DvM7GgmwR0UVFeRfBik/y6a NvzLTga/CB8+ZAjxma40D836CiUL/2U9NTckBs0s=
Message-ID: <>
Date: Tue, 28 Aug 2012 11:09:55 +0200
From: Matthijs Mekking <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Shawn Emery <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5a1pre
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 ( [IPv6:2001:7b8:206:1::1]); Tue, 28 Aug 2012 11:09:55 +0200 (CEST)
X-Mailman-Approved-At: Tue, 28 Aug 2012 02:41:40 -0700
Subject: Re: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Aug 2012 09:10:02 -0000

Hash: SHA1

Hi Shawn,

Thanks for your review.

On 08/28/2012 09:22 AM, Shawn Emery wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
> This informational draft describes the operational practices for
> administrating a DNSSEC environment.  Specifically the management of
> keys and signatures in DNS.  The draft intends to obsolete RFC 4641.
> The security considerations section does exist and is somewhat terse in
> its explanation of mitigating spoofing and DoS attacks.  This should be
> expanded or at least a reference made.

How DNSSEC mitigates against spoofing attacks and does not protect
against DoS attacks is explained in the DNSSEC RFCs (RFC 4033-4035). I
have added a reference to these documents. Also, I have explained a bit
more how not taking into account 'data propagation' properties will
cause validation failures, making secured zones unavailable to
security-aware resolvers. The proposed text is now:

   DNSSEC adds data origin authentication and data integrity to the DNS,
   using digital signatures over resource record sets.  DNSSEC does not
   protect against denial of service attacks, nor does it provide
   confidentiality.  For more general security considerations related to
   DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC
   4035 [RFC4035].

   This document tries to assess the operational considerations to
   maintain a stable and secure DNSSEC service.  When performing key
   rollovers, it is important to keep in mind that it takes time for the
   data to be propagated to the verifying clients.  Also important to
   notice is that this data may be cached.  Not taking into account the
   'data propagation' properties in the DNS may cause validation
   failures, because cached data may mismatch with data fetched from the
   authoritative servers.  This will make secured zones unavailable to
   security-aware resolvers.

Is this better?

> General comments:
> None.
> Editorial comments:
> Consistency: SEP is expanded, but not DS.

I have expanded DS at its first occurrence.

> s/purposes X will somewhere/purposes, X will be somewhere/
> s/such as e.g.  RFC 5011/e.g. RFC 5011/


The diff with the work in progress can be found here:


The diff also contains other reviewers changes.

Best regards,

> Shawn.
> --

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -