Re: [DNSOP] Error handling in CAA

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 22 November 2017 21:30 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 C8E8D124B18 for <dnsop@ietfa.amsl.com>; Wed, 22 Nov 2017 13:30:14 -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 5E5gWYS7gCGl for <dnsop@ietfa.amsl.com>; Wed, 22 Nov 2017 13:30:13 -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 35FE612957C for <dnsop@ietf.org>; Wed, 22 Nov 2017 13:30:13 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 005727A330A; Wed, 22 Nov 2017 21:30:11 +0000 (UTC)
Date: Wed, 22 Nov 2017 21:30:11 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop WG <dnsop@ietf.org>
Message-ID: <20171122213011.GU3322@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> <20171121205403.GT3322@mournblade.imrryr.org> <alpine.DEB.2.11.1711221205030.4416@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.1711221205030.4416@grey.csi.cam.ac.uk>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ic_E5hhd7bxlhFnEPNHojmeub_k>
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: Wed, 22 Nov 2017 21:30:15 -0000

On Wed, Nov 22, 2017 at 12:09:51PM +0000, Tony Finch wrote:

> > If the SOA lookup fails, then the domain is severely broken
> 
> No, it might just be private.

We are not using the same (mine is correct :-) definition of failure.
An NXDomain reply is not a lookup failure.  The security status of
the domain is available regardless of whether we get NoError with
some answers, NoError with no answers (aka NoData) or NXDomain.

A private sub-domain should return NXDomain on the public side of
the Internet, with that answer signed or not based on the security
status of the parent zone.  Having the query ServFail is where of
course you run into trouble.

My recommended algorithm for CAA probing is that any (really, as
in ServFail, ...) failed CAA probe be accompanied by an SOA probe
for the *same* domain.

If the SOA probe succeeds (including NXDomain), and is signed, then:

    * Signed NXDomain is sufficient to conclude that CAA does not
      exist either
    * Signed NODATA is sufficient to conclude that the zone is
      signed and CAA lookup failure must not be ignored.
    * Ditto for a signed SOA RRset.

If the SOA probe succeeds (including NXDomain), and is not signed,
then:

    * Unsigned NXDomain is sufficient to conclude (sans DNSSEC) 
      that CAA does not exist either.

    * Unsigned NODATA is sufficient to conclude that the zone
      is not signed and persistent CAA failure might eventually be
      ignored (sparing the domain owner the pain signal they need
      to take important corrective action, perhaps not a good idea).

    * Ditto for unsigned SOA RRset.

If the SOA lookup (really) fails, then the domain is broken.  Any
non-public sub-domains that want certificates, should not be broken
in this way.  Either appear in the public DNS, return NXDomain or
NODATA.  A wildcard CAA record might in fact be a good way to
present a non-public subtree to the outside world:

    internal.example.com. IN CAA ...
    *.internal.example.com. IN CAA ...

-- 
	Viktor.