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

Evan Hunt <each@isc.org> Sat, 09 May 2015 18:50 UTC

Return-Path: <each@isc.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 5AC491A8F4E for <dnsop@ietfa.amsl.com>; Sat, 9 May 2015 11:50:36 -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 tiOqZ2own-bq for <dnsop@ietfa.amsl.com>; Sat, 9 May 2015 11:50:32 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D2E1A8BB4 for <dnsop@ietf.org>; Sat, 9 May 2015 11:50:31 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id DE9373493BF; Sat, 9 May 2015 18:50:28 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id C3B7A216C1C; Sat, 9 May 2015 18:50:28 +0000 (UTC)
Date: Sat, 09 May 2015 18:50:28 +0000
From: Evan Hunt <each@isc.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20150509185028.GB74933@isc.org>
References: <553EBF02.3050703@gmail.com> <CAJE_bqc-T75k3sQZKtAF1VHp49biGn+Es5v5FivNSz5e3oB-Cg@mail.gmail.com> <CAHw9_iL9RLp0jynT0m_D6dGZYhmdonvBC-5ifTdB63eh5gvBeg@mail.gmail.com> <CAJE_bqesFPG6d3UsFmtFRjUBQqfifHkaBMR0sXAaNKuN10HL4A@mail.gmail.com> <CAHw9_iLbx_soi1+LaSwMKarLcT1kBCrFdaX8diwMVZp70KeePA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHw9_iLbx_soi1+LaSwMKarLcT1kBCrFdaX8diwMVZp70KeePA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Ku8TFIo8SHgV4obj_hOaAqMky6I>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, 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 18:50:36 -0000

On Sat, May 09, 2015 at 03:08:11PM +0200, Warren Kumari wrote:
> "It is RECOMMENDED that implementations warn operators (or treat as an
> error) if they attempt to add an NTA for a domain that has a
> configured positive trust anchor."

You still need to say what happens if the implementation decides to warn
instead of treat it as an error.

Actually, weirdly enough, after I implemented NTA's in BIND, one of the
very first applications somebody came up with for them was to temporarily
disable DNSSEC validation by setting an NTA for ".".  This was seen as
better than "rndc validation off" because he didn't have to send "rndc
validation on" afterward; it would just quiety switch itself back on
after a minute.  It's... actually a pretty clever hack, and I don't
really want to disable it.

May I suggest: "An NTA placed at a node where there is a configured
positive trust anchor takes precendence over that trust anchor, effectively
disabling it.  Implementations MAY issue a warning when this occurs."

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.