Re: [Spasm] CAA erratum 4515

Jacob Hoffman-Andrews <jsha@eff.org> Fri, 10 March 2017 20:22 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 81FE3129452 for <spasm@ietfa.amsl.com>; Fri, 10 Mar 2017 12:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 hw5lqVbSiIlc for <spasm@ietfa.amsl.com>; Fri, 10 Mar 2017 12:22:33 -0800 (PST)
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 01CF3129424 for <spasm@ietf.org>; Fri, 10 Mar 2017 12:22:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=lJAsRenkMzGhrMGuSiLQrw/zSLKTjfZj9MFSVfNEFxw=; b=JphGtxV7RDTvRPKQyUrhidZBHFc19PxGJB4V9WJfg05hY7MckZXtbXDUlupwZdVpnw/D5y+npW2DVtXpQlK9SwXUK6neIXv5/Si7Hdx642uG4P8qV4YvJkUsvSeQR4K4Wjeue3IJheijy4qqzGTUYr5gpeO98dSo+CiZURg91Jo=;
Received: ; Fri, 10 Mar 2017 12:22:34 -0800
To: Ryan Sleevi <ryan-ietf@sleevi.com>
References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <CAErg=HFtk0EKASTpWwNVhcT4zk2+ei-KPv=cMYDQej2oGJi=rw@mail.gmail.com> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <CAErg=HGT7FyDKgm8cAUojhGDOzLUkn=bw1Xdghbqnxw-79zQiw@mail.gmail.com> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <CAErg=HFeAMLF4vY59oTBh=OpeChyG8SpJ406cE=CpjouA9fq8w@mail.gmail.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org>
Date: Fri, 10 Mar 2017 12:22:30 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAErg=HFeAMLF4vY59oTBh=OpeChyG8SpJ406cE=CpjouA9fq8w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------ACC8B9E13D8915D03D20EB2A"
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/6lNK8S8LTPIvmsHqqe7snQ4GHGc>
Cc: Patrick Donahue <pat@cloudflare.com>, Gervase Markham <gerv@mozilla.org>, Phillip Hallam-Baker <philliph@comodo.com>, Peter Bowen <pzb@amzn.com>, SPASM <spasm@ietf.org>, Rob Stradling <rob.stradling@comodo.com>
Subject: Re: [Spasm] CAA erratum 4515
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 10 Mar 2017 20:22:35 -0000

On 03/10/2017 11:43 AM, Ryan Sleevi wrote:
> I'm going to introduce one more assumption: the CDN issues
> certificates for their own internal subdomains, and wants a CAA policy
> for those. This is necessary to explain why the CDN sets any CAA
> records at all in the Self-managed case. And I think this is what's
> implied by your examples - right?
>
> I think "internal subdomains" introduces an unnecessary degree of
> ambiguity, especially with your example of "enterprise.ca
> <http://enterprise.ca>". I'm not sure if this is indicative that we're
> talking past each other or not.
>
> Both organizations want to set their own CAA policy as appropriate. I
> think that should be uncontroversial and without complication.
Agreed. To aid understanding, could you re-explain in your own words why
your examples show the CDN setting CAA records in the Self-managed case?
I copied that into my own examples for consistency, by I had to guess at
the reasons.

> These configurations are a little confusing, since you don't define
> goals. I assume the goals in this example are:
>  (a) Every domain and subdomain in the example is covered by a CAA
> policy, and
Can you confirm whether this is an implicit goal in your examples?

>
>     Now, if we like, we can factor out the CAA records that appear in
>     every example: those for the base domains staffie.dog, beagle.dog,
>     terrier.dog, and hound.dog. That allows us to look at the
>     differences between the worlds more closely, and see what CAA
>     records are required beyond those:
>
>
> I'm sorry. At this point, I'm no longer able to follow your logic,
> despite having read this several times.
Sure, I'll re-explain: If you look at the examples, you'll find they all
have these four CAA entries in common:

staffie.dog.            CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"

The "reduced examples" are simply the regular examples with those common
entries removed.

> I personally find this structure much harder to follow, so I may have
> missed things - if only because you're describing the permutations for
> trampoline and non-trampoline in the same configuration, and I think
> that makes it harder to compare the implications of these two
> configurations - which was very much my objective in providing further
> discussion.
My goal here was to give trampoline and non-trampoline examples their
own distinct names, so we can compare them side-by-side in each world.
The conclusion I come to is that there is not a significant difference.

Maybe we can come at this from a different angle: I think you are saying
that in the non-tree-climbing world, CDNs would need to use the
trampoline to make it possible (or convenient?) to express a certain CAA
policy.

You and I agree that forcing CDNs to use trampolines to express a
certain CAA policy is undesirable. I disagree that trampolines are
necessary in either the tree climbing or the non-tree-climbing world.
Let's try to answer some specific questions:

- Are you arguing that trampolines make a certain policy possible, or
just more convenient?
- In the non-tree-climbing world, are you arguing that trampolines are
necessary for Self-managed, Externally-managed, or both?