Re: [lamps] Next steps on CAA

Jacob Hoffman-Andrews <jsha@eff.org> Wed, 04 October 2017 18:04 UTC

Return-Path: <jsha@eff.org>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B64134317 for <spasm@ietfa.amsl.com>; Wed, 4 Oct 2017 11:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 yh3_9s-8SWRH for <spasm@ietfa.amsl.com>; Wed, 4 Oct 2017 11:03:58 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00F2133245 for <spasm@ietf.org>; Wed, 4 Oct 2017 11:03:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=VVnnuW6fVwBirFuLvYRKsO1RYd44FFEtNtu+eLgeCj4=; b=P8sKzaC9VXco/iIiX0z88F34lBqTF8FWNssexnWBGHfX93ZuwBYF/TejbonQ49/Tgnygg13/hm/UzaTzHm9QdhvJY85v3j/OfIZqTwt6gmVJ9kPNKBK5hzJmEziLipoLQFCUPdyZkezEgyMQAT2YsgCgsr+ZIyC5f+QR07+nTtw=;
Received: ; Wed, 04 Oct 2017 11:03:55 -0700
To: spasm@ietf.org
References: <CAMm+Lwg+mR9DAfgc0gRo0oyM0N1sBG0FcSmO+3MV_U4kJctrxQ@mail.gmail.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <358e44b4-5b50-03bd-9d6f-d0b5575a0833@eff.org>
Date: Wed, 04 Oct 2017 11:03:57 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwg+mR9DAfgc0gRo0oyM0N1sBG0FcSmO+3MV_U4kJctrxQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ewf8iAv2cqS1_5ZmvfuK57goLYI>
Subject: Re: [lamps] Next steps on CAA
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 18:04:00 -0000

On 10/04/2017 07:15 AM, Phillip Hallam-Baker wrote:
> Before writing any text, I would like us to decide what the text should
> say. There is no point in wordsmithing until we know what we want to say.

I've published an individual draft on it, and gotten some feedback:
https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt.
I'm fairly sure the revised algorithm there, which is equivalent to
erratum 5065 plus some clarification about DNAMEs, is what we want to
say. I'd like to start our wordsmithing on that basis, since we've
already done some discussion.

> 1. A fix to the specification part describing the new discovery algorithm

Yep, +1.

> 2. An appendix that sets out worked examples for the following
> 
> * Site publishes CAA records without DNSSEC
> * Site publishes CAA record with DNSSEC

There have been problems with CAA processing on DNSSEC-signed domains,
but they are not typically due to incorrect publishing of CAA records.
They are implementation problems in authoritative resolvers, typically
when the resolver incorrectly signs an empty response. In other words,
the problems crop up when DNSSEC is present, but no CAA records are
present. Examples of signed records wouldn't help here, but describing
the class of DNSSEC implementation errors that are commonly surfaced by
CAA lookups would. I'm happy to produce a paragraph to that effect.

> On the design decisions side, I can only see one actual decision point.
> There are many points where the issue is what do the DNS specs say, but
> the only part where I can see us having a choice is on whether to
> support recursive tree climbing on a prefixed name.

IETF makes decisions based on "rough consensus and running code."
Erratum 5065-style CAA is the epitome of running code; all publicly
trusted CAs are required to implement it. We should formalize that into
an RFC before we consider new, incompatible alternatives.

> These issues were discussed when CAA was originally proposed

I went back and reviewed *all* the discussion on the PKIX mailing list
from when CAA was first proposed:
https://mailarchive.ietf.org/arch/search/?email_list=pkix&q=caa.

Between draft 11 and draft 12 we went from no tree climbing at all, to
tree climbing on the issuance domain, plus tree climbing on all aliases:

https://tools.ietf.org/html/draft-ietf-pkix-caa-11#section-3
https://tools.ietf.org/html/draft-ietf-pkix-caa-12#section-4

The discussion at the time was between querying only the leaf node, vs
leaf node + delegation point, vs tree climbing on the issuance domain.
There was no constituency asking for tree climbing on the issuance
domain *plus* tree climbing on the aliases.

When tree climbing was drafted, the example text stood as it stands
today; describing erratum 5065-style processing, in contradiction to the
formal algorithm drafted at the same time. It seems like the spirit of
the room was to only do tree climbing on the issuance domain. Tree
climbing on CNAMEs was introduced as a byproduct of trying to re-specify
CNAME processing instead of relying on RFC 1034's definition of CNAME
processing.

I think
https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt
is the ideal approach, and solves immediate problems we have without
introducing new complexity.