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

"Klaas Wierenga (kwiereng)" <> Thu, 07 August 2014 10:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CB88B1B27E5; Thu, 7 Aug 2014 03:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.502
X-Spam-Status: No, score=-16.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id foQHiKCiDKqs; Thu, 7 Aug 2014 03:30:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBFD21A00EA; Thu, 7 Aug 2014 03:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2136; q=dns/txt; s=iport; t=1407407457; x=1408617057; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=y6mHSe/A5Lqofg+nQsc17aVTk/6IEjBRvK6VKBW/gpo=; b=ETitYio9YMjAiDK70myHFEqwV8oa30GKgt6pMQmuziH6DdXJlJNdantx JwSAXIC13vyv4w04AdU+dRNDxn7OS/XrW5ykXQSx/DSr+8Np2cSW2Rmfj RZoQlA2gwHF8GYxNVXOZ9qCTTQahGnhnXucABh7b03I8RCmAup17XO6qR E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FAPVU41OtJV2d/2dsb2JhbABagw1SV68LnT8KhnVTAYEWFneEAwEBAQMBAQEBaxALAgEIGC4nCyUCBAESiDoIDcN6F450JTqDL4EcBZUwhmiBVJMZg1dsgQQ
X-IronPort-AV: E=Sophos;i="5.01,817,1400025600"; d="scan'208";a="67259686"
Received: from ([]) by with ESMTP; 07 Aug 2014 10:30:35 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s77AUYpg001436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 10:30:34 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 05:30:34 -0500
From: "Klaas Wierenga (kwiereng)" <>
To: "" <>, "" <>, "" <>
Thread-Topic: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
Thread-Index: AQHPsiqeTZ2SSkFU00uUSw5pbueKeQ==
Date: Thu, 07 Aug 2014 10:30:33 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Aug 2014 10:30:59 -0000

Sorry, dropped a letter in copy/paste of draft name 

Sent from my iPad

> On 07 Aug 2014, at 11:45, "Klaas Wierenga (kwiereng)" <> wrote:
> Hi,
> 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,
> Klaas
> _______________________________________________
> secdir mailing list
> wiki: