Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 15 May 2018 18:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEB112E86D for <dnsop@ietfa.amsl.com>; Tue, 15 May 2018 11:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3MSiKxyiJr_q for <dnsop@ietfa.amsl.com>; Tue, 15 May 2018 11:48:19 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB1A12E858 for <dnsop@ietf.org>; Tue, 15 May 2018 11:48:19 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 7800A7A3309 for <dnsop@ietf.org>; Tue, 15 May 2018 18:48:18 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Tue, 15 May 2018 14:48:17 -0400
References: <20180515182906.5E92F2698BF1@ary.qy>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <20180515182906.5E92F2698BF1@ary.qy>
Message-Id: <8E5D5D6C-6893-473D-A2FE-DCB0B46E7518@dukhovni.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-ppqyhtpeEHDL3Eu1hHHxpMoEVs>
Subject: Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 15 May 2018 18:48:21 -0000


> On May 15, 2018, at 2:29 PM, John Levine <johnl@taugh.com> wrote:
> 
> I think you will find that attempts to legislate against being stupid
> do not generally turn out well.  It makes sense to check for mistakes
> that might screw up the upper level name server like an invalid
> algorithm number, but if they want to shoot themselves in the foot,
> there's not much we can do about that.
> 
> There's no way to make a list of every possible stupid thing that
> someone might do, so I wouldn't try.

Some of the more subtle, but still very important failure modes
are not obvious unless *tested*.  It is would be a disservice to
the ecosystem to blindly turn on only partly working DNSSEC which
is actually broken in important ways.

Section 3.4 says:

   The Registration Entity, upon receiving a signal or detecting through
   polling that the child desires to have its delegation updated, SHOULD
   run a series of tests to ensure that updating the parent zone will
   not create or exacerbate any problems with the child zone.  The basic
   tests SHOULD include: [...]

And while we can't enumerate all possible breakage, there are clear
mistakes that are comparatively common now, and which would become
much more prevalent if enrollment is made easier with no due care to
ensure that we're not adding to the problems.

   * Incomplete NSEC chains that break denial of existence of
     the TLSA records of any explicit (or implicit zone apex)
     MX hosts.

   * SOA signatures that are invalid (typically modified after signing)

   * RRtype-based query filtering that drops TLSA/CAA/... queries.

   * ... and a few more ...

The above are not made-up hypotheticals, they are actually observed in
sufficient numbers to establish a pattern of likely failure modes that
need to be tested.  I have around ~200 samples that provide strong evidence
of the most common failure modes.

We can perhaps quibble over which failures might be ignored, but it
would be irresponsible and counter-productive to ignore them all.

-- 
-- 
	Viktor.