Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

"Rose, Scott W." <scott.rose@nist.gov> Wed, 06 May 2015 13:34 UTC

Return-Path: <scott.rose@nist.gov>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B541A916E for <dnsop@ietfa.amsl.com>; Wed, 6 May 2015 06:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KdNSRDWTHfCD for <dnsop@ietfa.amsl.com>; Wed, 6 May 2015 06:34:01 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1115A1A916B for <dnsop@ietf.org>; Wed, 6 May 2015 06:34:00 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 6 May 2015 09:33:33 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 6 May 2015 09:33:55 -0400
Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id t46DXkvl029111 for <dnsop@ietf.org>; Wed, 6 May 2015 09:33:46 -0400
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "Rose, Scott W." <scott.rose@nist.gov>
In-Reply-To: <793F7CBB-198C-438D-9AD3-F1414E6011F3@vpnc.org>
Date: Wed, 06 May 2015 09:33:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <E146311E-22F5-4CF8-BFDD-5CA4B675B0ED@nist.gov>
References: <553EBF02.3050703@gmail.com> <793F7CBB-198C-438D-9AD3-F1414E6011F3@vpnc.org>
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
X-NIST-MailScanner-Information:
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/ZIqjl0vfu_toHifLlaLwewFegaI>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2015 13:34:04 -0000

I think the draft is just about ready for publication as well.

On May 5, 2015, at 5:53 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> This document has progressed very well and is nearly ready for publication.
> 
> Related to an earlier thread about intended status: "Informational" is most appropriate here because the document is all about proposed operations but no "best current practice". There is no problem with WGs producing Informational RFCs, and Informational RFCs can have RFC 2119 language.
> 
> In Section 2, there should be a new paragraph after the first paragraph that describes why the "reasonable attempt" in the first paragraph is needed to determine whether the attacker has partial control of the zone, or is just mounting an on-path attack between all the nameservers and the recursive.
> 
> In Section 2, it talks about "a popular domain name" but don't say how to determine that. Giving examples of sources of that data would be valuable.
> 
I would recommend local query logs, naturally.  


> 
> In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly called "Altering Users of NTA Use".
> 
There is a security consideration there, reading between the lines - in that this is broadcasting a spoofable name to the world.  However, a "Altering User's" section would be a good addition to include text about apps that may break if it is known they demand to see the AD bit set in responses.

Scott



===================================
Scott Rose
NIST
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================