Re: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10

"Livingood, Jason" <> Mon, 29 June 2015 12:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3AF5B1A90EC; Mon, 29 Jun 2015 05:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.926
X-Spam-Level: **
X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tO73bPmohRgp; Mon, 29 Jun 2015 05:57:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 990361A9068; Mon, 29 Jun 2015 05:57:37 -0700 (PDT)
X-AuditID: 44571fa7-f796a6d000005411-d1-559140bfb87c
Received: from ( []) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id EA.48.21521.FB041955; Mon, 29 Jun 2015 08:57:36 -0400 (EDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Jun 2015 08:57:31 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 29 Jun 2015 08:57:30 -0400
Received: from ([fe80::3aea:a7ff:fe12:37f4]) by ([fe80::3aea:a7ff:fe12:37f4%19]) with mapi id 15.00.1044.021; Mon, 29 Jun 2015 08:57:30 -0400
From: "Livingood, Jason" <>
To: Yaron Sheffer <>, IETF Security Directorate <>, The IESG <>, "" <>
Thread-Topic: SecDir review of draft-ietf-dnsop-negative-trust-anchors-10
Thread-Index: AQHQqs3939n5Q1LeNESf2OzLcK//sJ3DgLCA
Date: Mon, 29 Jun 2015 12:57:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1B6B587108CBDjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KR0ODp0j3gMDHU4P4XIYvjtz4zW8z4M5HZ 4sPChywWq+7PYHdg8dg56y67x5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV8Wf+S7aCvSYV WzbOZ2tgfK7dxcjJISFgIrF43UQWCFtM4sK99WxdjFwcQgLbmCT+N7xhhHAOMkq8a9nBCuEc ZpToO/CUCcI5yShx6sI6NpB+NgEbienbjjKDJEQEPjJK/Fz5gRUkISzgIbFj5SomEFtEwFNi 2YVbbBC2kcT653vBbBYBVYljr36xg9i8AvYSh/r/MYLYQgIaEl+v/AWLcwpoSqxcsxpsJiPQ sd9PrQGbySwgLnHryXwmiCcEJJbsOc8MYYtKvHz8D6xeVEBP4tCsj1CPGkhsXboPylaQ2L5/ GwvEnGSJc5s/MUHcIChxcuYTFogb9CQu7brMDlEvLnH4yA7WCYxSs5CsnoWkfRaSdoi4jsSC 3Z/YIGxtiWULXzPD2GcOPIbqdZDobjyJomYBI8cqRrmCxOSU5NyM/NISA0O95MSknFS95Pzc 5MTiEhC9iRGYNlzC5ZfvYLz3wukQowAHoxIP7wvLiaFCrIllxZW5hxglOJiVRHgvb54QKsSb klhZlVqUH19UmpNafIhRmoNFSZz31fTeUCGB9MSS1OzU1ILUIpgsEwenVANjR2rWnzV/462i bJZ7WYjnX31dqr/46B11ZQ+fM/25qXNz4vkfbE1h5Fpsvd63kkWPTWFVW0nA3gPdzoLK56/Y JZm8U+FrLez8HSfs9vTqua8vgsp7D522uPK14u2R9XdN55Znsf1oOeoa1/na8Zpay4c/567t 4uKS+++csFupsftzHv/tZiMlluKMREMt5qLiRAA/FodiFwMAAA==
Archived-At: <>
Subject: Re: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10
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: Mon, 29 Jun 2015 12:57:39 -0000

On 6/19/15, 4:24 PM, "Yaron Sheffer" <<>> wrote:

This is more of a rant than a review, however it presents a security perspective that seems to be at odds with the operational-first perspective of the document.

Keeping in mind your feedback is as you say a rant, I will happily respond below and try to shed some more light on this. ;-)

As an aside, DNSSEC validation penetration would not be where it is today without NTAs. They have become critical; without them it is unlikely DNSSEC would be particularly viable. This is the unfortunate reality, and implementers are doing their best to make the network & namespace more secure within the boundaries of operational reality.

Even assuming that 99.9% of us will continue to trust ISPs for DNS
resolution, IMHO the proposed solution would be better off with more
automation and less celebration of "trained technical personnel". For
example, the document has a SHOULD level requirement to test the NTA
"periodically" in order to eventually remove it.

Automated vs. manual was extensively discussed in the WG and the issue concluded with the text in the document now. Among the concerns with making this more automated were whether an automated, centralized DNSSEC-disablement function would itself be a juicy target of attack to enable downgrade attacks. Aside from that, DNS recursion has always been operated locally, on a distributed basis, and there is local policy such as NTAs that has traditionally a part of this. In the end, the WG felt that not automating this was better than automating it.

How about an
alternative that shifts the responsibility to DevOps or to the actual
vendors, and also empowers the .1% who maintain their own resolvers:

"NTA implementors MUST attempt to validate the domain in question once every MINUTE for the period of time that the Negative Trust Anchor is in place, until such validation is again successful, and MUST remove the NTA as soon as that happens."

FWIW, the document does not have an RFC 2119 reference and so that sort of requirement text would not carry much weight. In practice, however, implementers use NTAs sparingly and are usually in very close contact with the domain owner and are often advised by them of an estimated MTTR.