Re: [DNSOP] Error handling in CAA
Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 18 November 2017 21:10 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 A279412009C for <dnsop@ietfa.amsl.com>; Sat, 18 Nov 2017 13:10:03 -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 c8IbIZLMAGcU for <dnsop@ietfa.amsl.com>; Sat, 18 Nov 2017 13:10:02 -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 D8C2012008A for <dnsop@ietf.org>; Sat, 18 Nov 2017 13:10:01 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 86AAE7A330A; Sat, 18 Nov 2017 21:10:00 +0000 (UTC)
Date: Sat, 18 Nov 2017 21:10:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop WG <dnsop@ietf.org>
Message-ID: <20171118211000.GR3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IhIAQVxCsyRSyQcZ_EwI0vgudlc>
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: Sat, 18 Nov 2017 21:10:03 -0000
On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote: > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf > > > CAs are permitted to treat a record lookup failure as permission to issue > > if: > > - the failure is outside the CA's infrastructure; > > - the lookup has been retried at least once; and > > - the domain's zone does not have a DNSSEC validation chain to the ICANN root. 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. * If the lookup returns NoError with AD=1 (a validated SOA record or a validated NoData), the domain is signed, do not tolerate CAA lookup failure. Ditto for "NXDomain". (As I've repeated too many times, NoError, NoData and NXDomain are not lookup failures). * If the lookup returns NoError with AD=0 (an insecure SOA record or an insecure NODATA), the domain is not signed. Ditto for NXDomain. Tolerate persistent CAA lookup failure. > However, if you're using a standard recursive resolver inside your own > infrastructure, and you get a SERVFAIL, how do you distinguish whether > that was a DNSSEC validation failure or another type? See above, the CA should not attempt to distinguish between different faiure modes. * All failures for domains *not known* to be "insecure" should be fatal. * Persistent CAA lookup failure for *known* "insecure" domains (AD=0 with NoError, NoData or NXDomain) can be ultimately ignored as a software or configuration issue with the remote nameservers. I include NXDomain, because I think (correct me if I'm wrong) CAs may issue certificates for (internal) names that don't appear on the public internet, when the customer controls a public prefix. > I realize the > extended-error draft will help enormously with that, but I'm looking for > a solution that can be deployed before that is done. It is best to not attempt to read the tea-leaves. You can reliably determine which domains are insecure. Your validating resolver will include the AD bit with the SOA lookup result. If even SOA lookups fail, the domain is busted, and needs to be fixed on the customer's end. > One idea: Run two > recursive resolvers, one validating and one not. If you get an error > from both, it's a network error; if you get an error from the validating > one and success from the non-validating one, it's a DNSSEC error and you > should refuse issuance. This is complicated. > A second issue: How does one determine automatically whether a failure > is "outside a CA's infrastructure?" This was inserted as a bit of a > handwave to get the ballot passed, but it would be nice if we could > formalize this concept, or declare that it's unenforceable. That language looks misguided to me. -- Viktor.
- [DNSOP] Error handling in CAA Jacob Hoffman-Andrews
- Re: [DNSOP] Error handling in CAA Mark Andrews
- Re: [DNSOP] Error handling in CAA Viktor Dukhovni
- Re: [DNSOP] Error handling in CAA Tony Finch
- Re: [DNSOP] Error handling in CAA Viktor Dukhovni
- Re: [DNSOP] Error handling in CAA Phillip Hallam-Baker
- Re: [DNSOP] Error handling in CAA Tony Finch
- Re: [DNSOP] Error handling in CAA Viktor Dukhovni
- Re: [DNSOP] Error handling in CAA Tony Finch