IETF Logo Mail Archive

Re: [DNSOP] Error handling in CAA

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 21 November 2017 21:00 UTC

Return-Path: <hallam@gmail.com>
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 4B693127076 for <dnsop@ietfa.amsl.com>; Tue, 21 Nov 2017 13:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 JYC9SqcNAOSZ for <dnsop@ietfa.amsl.com>; Tue, 21 Nov 2017 13:00:42 -0800 (PST)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA8A126BF6 for <dnsop@ietf.org>; Tue, 21 Nov 2017 13:00:42 -0800 (PST)
Received: by mail-ot0-x230.google.com with SMTP id g104so11769047otg.7 for <dnsop@ietf.org>; Tue, 21 Nov 2017 13:00:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Yn2ksl0VfQAFkQg7HC1AdfcqX6aRHiIx+TH5R3FjkV4=; b=SUwegZJh9Q3Po2tNcm/squNP0sfgYhxVubp/zVoYyHi4naGM+cBalIbV5AKLBDYDnw xemTGVGtZTkkQiBYyfCA2eKOXonctN69wdcPMI+lP/LmzjmXUFv1uBpD/R2t6yjD9HZR DHulU4Wyp19xL0B0vVkUtmksBkUJXlQ02Q5nQk1k+ZSUfxf0X/iaFI7R7NlCl1kaVmjY ZZfJ2AJtc4gvqWmTp2yi23X27sev+SvnqMPMn4G422DikutRTI1OjZRAmEzHcQ/Bbr00 JZAEbE+isa79BNgpNq0CoxiwIWV6ucqj/RkIXomAkhSQaP85/tmLroExf+8ZlrrYRa4b tTBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Yn2ksl0VfQAFkQg7HC1AdfcqX6aRHiIx+TH5R3FjkV4=; b=nbqgFg0lEgWpFmDGXBgb5KusfWfTzgPF7tuI5VLefwYgjID/mLe7qRKLoV7/tlwIq8 UKEun1h3OaNgtkvrOHF2/a6PcSqy7k0qNnxnDktjrkD11iDIvuWdeclzxeN2wv50gKGI LhQoJz0cadmk/vjhHrOLzorbZJK6B2RD0wEgDD7we9hOP4XjFROH45sBwcpBT01Mbii+ EeDxNJV0OfJT9vYY8ilz8UYgRfHMT2/o739IsGrcUG2aR4epNx2qmOlQWVzDy6EDZsO1 UAUypqkL94Cj6xgWUchpv51IxqCrP5etsBdb5vMm15E7Yi7PEutQco2pCU8k38LDqHSk XS6w==
X-Gm-Message-State: AJaThX40FgfMMQGy1hD3NsSsRFDeOGNGygj2CLkNGbpbMv3pGD00PhHM wBxjY8YshJbjlHPnsRwaZN7ncdSrkSLa32d5/60=
X-Google-Smtp-Source: AGs4zMYbpS9NdyUEpS7VjlckNX3DCshxZHl0g9pr9etpIWjoUlV42oJWgci1+5HPCRhvRbBHQSCmrPZ9z9JTxhNzUrY=
X-Received: by 10.157.91.97 with SMTP id e30mr12526355otj.196.1511298041122; Tue, 21 Nov 2017 13:00:41 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.66.145 with HTTP; Tue, 21 Nov 2017 13:00:40 -0800 (PST)
In-Reply-To: <20171121205403.GT3322@mournblade.imrryr.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>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 21 Nov 2017 16:00:40 -0500
X-Google-Sender-Auth: jR99c4ArstDyuPENgao0jG5tnN4
Message-ID: <CAMm+LwhGtXdJD3qyXBbfoTRQN4go8z8SyqjbaLt64MpUmUrk6w@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/907U-UwhnlmyzHRdZhRJSttO89Q>
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 21:00:43 -0000

On Tue, Nov 21, 2017 at 3:54 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 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.

If the domain is broken, validation is going to fail as well. Which
may prove a useful cut.

v2.23.0 | Report a Bug | By Email