[secdir] secdir review of draft-ietf-dnsop-as112-dname-04

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Thu, 07 August 2014 09:45 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DC6231B28C6; Thu, 7 Aug 2014 02:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id G7-JQhVDHLs3; Thu, 7 Aug 2014 02:45:06 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5911B2A3E; Thu, 7 Aug 2014 02:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1672; q=dns/txt; s=iport; t=1407404703; x=1408614303; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fczTejjFbCATVq7sdkYX9aaNzb5cW/usZi+feUa36K0=; b=EDyuragKEyk9XhneMVUmw6ijE8253uW151C+l+i6X72LSUZFvnoldbYz EKDp9LQQRj8k+QwUkPzNmPf/GOmKjDiZ1Yc6DDacAKo3jEp4fC4syYCri jxPLqy9G7Ek+0MSBy+ovpAavhkDjnNr079X4vcXj/BO13YTQl4YnIPcmp M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAGxK41OtJA2I/2dsb2JhbABagw2BLdUsFneECoELAYEAJwQBiFTDdheOdIQOgRwFnBiUbYNXgXBC
X-IronPort-AV: E=Sophos;i="5.01,816,1400025600"; d="scan'208";a="345695938"
Received: from alln-core-3.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 07 Aug 2014 09:44:45 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com []) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s779ijBq002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 09:44:45 GMT
Received: from xmb-aln-x12.cisco.com ([]) by xhc-rcd-x10.cisco.com ([]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 04:44:45 -0500
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" <draft-ietf-dnsop-as112-dnam.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-ietf-dnsop-as112-dname-04
Thread-Index: AQHPsiQ3f8OY5L4Ee0OTmhRUsiOAuQ==
Date: Thu, 07 Aug 2014 09:44:44 +0000
Message-ID: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <DA2B8B287194A4419D4BD34BE3145816@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TPcfmjEyE9edvGVDGqsRX3xefjE
Subject: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 07 Aug 2014 09:45:10 -0000


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 believe this document is "ready with issues."

The document describes adding and dropping of zones for AS112, the zone that is meant rot act as a sinkhole for reverse lookups for addresses that are for private-use only.

I think the document is clearly written and with my limited understanding of DNS it all seems to make sense from a technical point of view. 

What I am not so sure of however is the statement in the security considerations: 

"This document presents no known additional security concerns to the Internet.
For security considerations relating to AS112 service in general, see RFC6304bis]."

And in the introduction

"The AS112 project does not accommodate the addition and removal of
   DNS zones elegantly.  Since additional zones of definitively local
   significance are known to exist”

It appears to me that moving from a static list of well known ranges as defined in 6304bis to a dynamic adding and dropping of IP-address ranges that are "of definitively local
   significance” is prone to error, potentially leading to blackholing valid address space, either on purpose or by accident. I may show my ignorance here, but I feel that a discussions as to why that risk doesn’t exist is warranted. 

Hope this helps,