Re: [DNSOP] Error handling in CAA

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 21 November 2017 20:54 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 590EB129BCD for <dnsop@ietfa.amsl.com>; Tue, 21 Nov 2017 12:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 y2mk32-z7UQm for <dnsop@ietfa.amsl.com>; Tue, 21 Nov 2017 12:54:05 -0800 (PST)
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 E4D221270AC for <dnsop@ietf.org>; Tue, 21 Nov 2017 12:54:04 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 171E67A330A; Tue, 21 Nov 2017 20:54:04 +0000 (UTC)
Date: Tue, 21 Nov 2017 20:54:04 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop WG <dnsop@ietf.org>
Message-ID: <20171121205403.GT3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> <alpine.DEB.2.11.1711201256440.32058@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1711201256440.32058@grey.csi.cam.ac.uk>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kVMbiO_IDD6N1GekMYJil8h5ywA>
Subject: Re: [DNSOP] Error handling in CAA
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, 21 Nov 2017 20:54:06 -0000

On Mon, Nov 20, 2017 at 01:10:43PM +0000, Tony Finch wrote:

> Viktor's message has lots of sound advice, though I have one correction:
> 
> > This language really should have been much more clear.  In particular,
> > the last item warrants clarification.  It is critical that the CA
> > determine the lack of a validation chain in a robust manner.  The
> > simplest approach:
> >
> >     * Request the SOA record of the domain.  If this lookup fails,
> >       (ServFail, Timeout, ...) stop, the domain's DNSSEC status is
> >       unknown.
> 
> No, you need to lookup the domain's DS records to determine its DNSSEC
> status.

Actually, I chose my recommendation of SOA lookup after some thought
and with care.  A domain may have no DS records, and yet be signed
because it is not a (delegated) zone apex domain.  Furthermore, an
SOA query elicts data from the domain itself, not the parent, and
thus ensures that any published DS records up the tree yield working
signatures for records in the zone containing the domain.

If the SOA lookup fails, then the domain is severely broken beyond
just "stoopid" blocking of CAA and other "novel" RRtypes, and so
there is no reason for the CA to be "forgiving" of such errors.
(Not that I have much sympathy for domains where CAA lookups fail
but other lookups do not, they really should feel some pain to fix
their DNS).

So I stand by the advice to issue "SOA" queries, they are far
simpler to implement correctly (without having to chase DS records
up the tree, cross check them against NS records, ...) and they
yield more useful information, namely whether:

    * A domain has working "insecure" DNS
    * A domain has working "secure" DNS
    * A domains is broken, and needs attention before CAA status
      can be determined or ignored.

-- 
	Viktor.