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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 09 May 2015 14:33 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 4B3DE1ACE6B for <dnsop@ietfa.amsl.com>; Sat, 9 May 2015 07:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 riE6LZQxNSeH for <dnsop@ietfa.amsl.com>; Sat, 9 May 2015 07:33:13 -0700 (PDT)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDB21ACE68 for <dnsop@ietf.org>; Sat, 9 May 2015 07:33:13 -0700 (PDT)
Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t49EXBGA054566 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 May 2015 07:33:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAHw9_i+uF3wumGD9uBCPhT=E961tA1tjBF+Zgnk8pRz4nJWDew@mail.gmail.com>
Date: Sat, 09 May 2015 07:33:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D379D4F9-3298-45BF-B08A-894623C6783A@vpnc.org>
References: <553EBF02.3050703@gmail.com> <793F7CBB-198C-438D-9AD3-F1414E6011F3@vpnc.org> <CAHw9_i+uF3wumGD9uBCPhT=E961tA1tjBF+Zgnk8pRz4nJWDew@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/fC_tH2WxCjyp7ykjxPxFv05L-sY>
Cc: dnsop <dnsop@ietf.org>
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: Sat, 09 May 2015 14:33:14 -0000

On May 9, 2015, at 6:07 AM, Warren Kumari <warren@kumari.net> wrote:
>> 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.
> 
> 
> DONE?
> "It is important to confirm that the comains is still under the
> ownership / control of the legitimate owner of the domain - this is to
> ensure that disabling validation for a specific domain does not direct
> users to an address under an attackers control. Contacting the domain
> owner allows the resolver operator to determine if the issue is a
> DNSSEC misconfiguration or an attack."
> 
> I'm not really sure if this addresses your concerns? If not, do you
> happen to have any suggested text?

Using your, expanding just a bit:

"It is important for the resolver operator to confirm that the domain is still under the
ownership / control of the legitimate owner of the domain in order to
ensure that disabling validation for a specific domain does not direct
users to an address under an attacker's control. Contacting the domain
owner and telling them the DNSSEC records that the resolver operator is seeing
allows the resolver operator to determine if the issue is a
DNSSEC misconfiguration or an attack."

> 
> 
>> 
>> 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.
> 
> DONE.
> I added: "An example of a list of "top N" websites is the <xref
> target="Alexa">"Alexa Top 500 Sites on the Web" </xref>"
> 
> Is this OK?

That's OK, but I would prefer to add in what Scott Rose suggested: ", or a list of the of the most-accessed names in the resolver's cache".

--Paul Hoffman