Re: [secdir] secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

"Livingood, Jason" <Jason_Livingood@cable.comcast.com> Sun, 29 May 2011 18:44 UTC

Return-Path: <jason_livingood@cable.comcast.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 79904E0736; Sun, 29 May 2011 11:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.436
X-Spam-Level:
X-Spam-Status: No, score=-108.436 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 C8GHfs7PSXCH; Sun, 29 May 2011 11:44:26 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A93EE0679; Sun, 29 May 2011 11:44:25 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127904555; Sun, 29 May 2011 14:44:22 -0400
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sun, 29 May 2011 14:44:21 -0400
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: Russ Mundy <mundy@tislabs.com>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMCTn9fR3di036FkigKoxmcb9XeZSkTl2A
Date: Sun, 29 May 2011 18:44:21 +0000
Message-ID: <CA080B2E.28969%jason_livingood@cable.comcast.com>
In-Reply-To: <BEDC9811-A413-4858-8F2C-27EE13417C30@tislabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA080B2E28969jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 29 May 2011 12:18:43 -0700
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ietf-v6ops-v6-aaaa-whitelisting-implications.all@tools.ietf.org" <draft-ietf-v6ops-v6-aaaa-whitelisting-implications.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
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: Sun, 29 May 2011 18:44:27 -0000

Thanks for your review, Russ. I'll be posting an updated –04 revision soon, once I make it through all the bits of other feedback in my queue. Some specific responses are inline below.

Thank you!
JL

On 5/2/11 3:58 PM, "Russ Mundy" <mundy@tislabs.com<mailto:mundy@tislabs.com>> 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.

I found the document to be well written as well as providing sound technical descriptions of the topic of DNS Whitelisting.

>From a security review perspective, I do have a suggestion for section 10 Security Considerations.  The section infers (at least to me) that there is something different or unique for configuring DNS Whitelist configuration protection from other configuration settings for name servers.  Unless I've misunderstood how servers actually implement whitelisting, it uses the same configuration mechanisms and files as any other name server ACL or many other name server configuration settings - _all_ the configuration settings for a name server should be protected so that only authorized individuals can change them.  Modifying the wording to say something to the effect of "Just as all configuration settings for name servers should be protected by appropriate procedures and systems ..."

[JL] Great suggestion — and that has been added to the upcoming update.



Russ Mundy