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

Warren Kumari <> Mon, 29 June 2015 14:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 66C321ACDDF for <>; Mon, 29 Jun 2015 07:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZGTQ6cMYWGUp for <>; Mon, 29 Jun 2015 07:57:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A9A41ACDEE for <>; Mon, 29 Jun 2015 07:57:25 -0700 (PDT)
Received: by oiax193 with SMTP id x193so119761696oia.2 for <>; Mon, 29 Jun 2015 07:57:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=paCySm2d/rwFqQuAFSKFJSMaYHixPxU73iRq8NVPgpE=; b=BmkLpjSem8vE7Hjzvzr7dch+e3igWSCY0/LRnSRTIEN0xqd2ZdIxiBqUk1nxXq9X5u PfH8oUH7+KLL7wW6oaoB9j4GgmzWoQYc/Q5KmnnrCFXxQpbqMuutOqkVMYooyrBbTpww lONPEvu5NRck3nlo8AeBtg89joEH2o6W194w69kY5R3dcOzgPq1AvxeFg7LWxrrZ8QYw jnlEF1c6vAwoREUcpqF5OeRFLppRtvihWnt6mBnhnCwlvt9GBQbDvj74AQXQnD623cIT WMqywqTYtgaq4PeXnN/jr5rMqX4xwuV5ZsNwzAdFsS+TyiSptvSqZiACE5LCPSbHq6jA w/hw==
X-Gm-Message-State: ALoCoQnHHoxInhWNpEe5D9AX0Ej/PLxLKsQ9L9EDjswK+Ju04z1XHpnoE9OViNdatBKh3hTc6ZpY
MIME-Version: 1.0
X-Received: by with SMTP id 200mr13796930oib.86.1435589845243; Mon, 29 Jun 2015 07:57:25 -0700 (PDT)
Received: by with HTTP; Mon, 29 Jun 2015 07:57:25 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 29 Jun 2015 10:57:25 -0400
Message-ID: <>
From: Warren Kumari <>
To: "Livingood, Jason" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, The IESG <>, IETF Security Directorate <>
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 14:57:32 -0000

On Mon, Jun 29, 2015 at 8:57 AM, Livingood, Jason
<> wrote:
> 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.

In addition, unless I'm very confused (entirely possible, no coffee
yet!) the .1% of people (and hopefully increasing) who run their own
resolvers are not affected by the NTA.

If you don't trust your ISP (and many people don't), you really
shouldn't be trusting them to do DNSSEC validation for you (they can
easily set the AD bit on all queries, clear it on some, etc), you
should do your own validation. If you do your own validation the NTA
is a no-op for you.

[ Apologies for delay, I was traveling (ICANN meeting...)]

> Regards,
> Jason
> _______________________________________________
> secdir mailing list
> wiki:

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.