[secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10
Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 19 June 2015 20:24 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0DE1B2A19; Fri, 19 Jun 2015 13:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOQ4CeK3IOlo; Fri, 19 Jun 2015 13:24:34 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABC81B2A16; Fri, 19 Jun 2015 13:24:34 -0700 (PDT)
Received: by wgbhy7 with SMTP id hy7so98116412wgb.2; Fri, 19 Jun 2015 13:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=LMoRhoPSAFeI7oGOtxCwpzvnzpjQBo/H/2hfrp7YC4Q=; b=sSXIKFYf5plI7m476NIURmTGd3wbL/WxWTmUr3ggkWnpyO3OUvs+YLlwuZqhF7Ipy4 0HWFldcHs4Jowed8yMGfcD8tVIyfOzoKwEuaP+1LcmMXjHa4AcvZMQJqVXMS0cLvSrQQ EXtIT5pfiqfcg/yItIBsocF8f/U4VLqCczn6udtOhCX5tLUfhzchH7TUZmwk81fdawYH VFLiYdyj36PXk86FWfw06svkzBsoPuvHkkKfTTDxDZB/TfmrpUpZguTjDk9cJK0JVxxl cCRgovdzKg/vn11h2wHUeyY+VIONglh+oAoyItsJ3ktuGUEI14+uSXKnG9OwCVkD94Lt DyRA==
X-Received: by 10.180.218.195 with SMTP id pi3mr9876972wic.71.1434745473067; Fri, 19 Jun 2015 13:24:33 -0700 (PDT)
Received: from [10.0.0.5] (bzq-79-180-17-102.red.bezeqint.net. [79.180.17.102]) by mx.google.com with ESMTPSA id a19sm5218363wiv.2.2015.06.19.13.24.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 13:24:31 -0700 (PDT)
Message-ID: <55847A7D.9030504@gmail.com>
Date: Fri, 19 Jun 2015 23:24:29 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-negative-trust-anchors.all@tools.ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/YdfnZZjzLVcsWnk2gCAYsopeuLY>
Subject: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10
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: Fri, 19 Jun 2015 20:24:36 -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. This document defines a process where an ISP can declare that certain domain names (whose DNSSEC records are deemed misconfigured) are not covered by DNSSEC. The server then provides DNS resolution in response to client queries, where otherwise the server would have failed those queries. Summary 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. Details I am hearing that this is a controversial draft, and I can see why. The draft explains very well what motivates the proposed mechanism, and the motivation makes sense, especially if you are an ISP. But I think the draft gives excellent instructions on improving the security of an inherently problematic usage model. As an individual or even as a company, the local ISP is not my friend. State-controlled ISPs in less developed countries have been known to steal traffic and fake certificates in order to attack their own subscribers. Commercial ISPs in more developed countries throttle or block certain types of traffic for various reasons. Moreover, the local ISP is best positioned to identify the owner of individual IP endpoints and perform point attacks on local subscribers. DNS is an obvious attack vector. 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. 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." Similarly, I would guess the process of establishing an NTA could be automated, e.g. by querying multiple major DNS operators over a period of time (maybe operators that are known to run the same brand of resolver). In general, automating the process is more likely to encourage deployment of DNSSEC by smaller ISPs than adding complex manual "best practices". Thanks, Yaron
- [secdir] SecDir review of draft-ietf-dnsop-negati… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-dnsop-ne… Livingood, Jason
- Re: [secdir] SecDir review of draft-ietf-dnsop-ne… Warren Kumari