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

Shawn Emery <shawn.emery@oracle.com> Wed, 29 August 2012 07:54 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2492021F84F2; Wed, 29 Aug 2012 00:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wl+tAxfej4h; Wed, 29 Aug 2012 00:54:24 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 392DD21F84D8; Wed, 29 Aug 2012 00:54:24 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7T7sLeC008896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 07:54:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7T7sLdi027182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 07:54:21 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7T7sKGU029694; Wed, 29 Aug 2012 02:54:20 -0500
Received: from [10.159.87.39] (/10.159.87.39) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 00:54:20 -0700
Message-ID: <503DCA56.5040301@oracle.com>
Date: Wed, 29 Aug 2012 01:52:54 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6
MIME-Version: 1.0
To: Matthijs Mekking <matthijs@nlnetlabs.nl>
References: <50065F08.1090307@oracle.com> <503C71A4.30709@oracle.com> <503C8AE3.8070906@nlnetlabs.nl>
In-Reply-To: <503C8AE3.8070906@nlnetlabs.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: iesg@ietf.org, draft-ietf-dnsop-rfc4641bis.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2012 07:54:25 -0000

On 08/28/12 03:09 AM, Matthijs Mekking wrote:
> 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?

Yes, this resolves my concerns.  Thanks.

>> 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/
> Changed.
>
> The diff with the work in progress can be found here:
>
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-12.txt&url2=http://www.nlnetlabs.nl/~matje/draft-ietf-dnsop-rfc4641bis.txt
>
> tinyurl: http://tinyurl.com/8luvedk
>
> The diff also contains other reviewers changes.

These updates look good.

Regards,

Shawn.
--