Re: [Spasm] CAA erratum 4515

Ryan Sleevi <ryan-ietf@sleevi.com> Sun, 12 March 2017 19:33 UTC

Return-Path: <ryan-ietf@sleevi.com>
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 0A17E12944F for <spasm@ietfa.amsl.com>; Sun, 12 Mar 2017 12:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 vdicP59b-4Cg for <spasm@ietfa.amsl.com>; Sun, 12 Mar 2017 12:33:47 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD40D1293F4 for <spasm@ietf.org>; Sun, 12 Mar 2017 12:33:47 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 65F02A00762E for <spasm@ietf.org>; Sun, 12 Mar 2017 12:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=saTAHFRsVsyBTQNZy5flSXUJp1g=; b= EJDAgSt65+JMGWNifQJSofmhCwfNh62eGERR8Sh+ivUxoDE0gFaQ0ylDytLLjXqf Z+WF/f9qblRpsOB16iVGTcso7iuGNcpie3sl0h8+Mm6G5BpbncvmF+yZQIf6dW6/ A2cg6CtkZw4HaWrLsuW/af+W+x5QbjWw7cFaUmhLnUI=
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 34B4FA00762C for <spasm@ietf.org>; Sun, 12 Mar 2017 12:33:47 -0700 (PDT)
Received: by mail-lf0-f41.google.com with SMTP id a6so56601952lfa.0 for <spasm@ietf.org>; Sun, 12 Mar 2017 12:33:47 -0700 (PDT)
X-Gm-Message-State: AMke39nn4IRuujsbGYha6bdnto3xoU6Ejb6C0swYnT9+hGwRYXCxhrsKIrKSrjlOOWc6mCbs491aF09EWwEHBQ==
X-Received: by 10.46.9.75 with SMTP id 72mr8843406ljj.10.1489347225474; Sun, 12 Mar 2017 12:33:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.193.197 with HTTP; Sun, 12 Mar 2017 12:33:44 -0700 (PDT)
In-Reply-To: <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org>
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> <20170311201904.GQ7733@mournblade.imrryr.org> <fede5d8f9f2c43518d8a3c502c60558a@usma1ex-dag1mb1.msg.corp.akamai.com> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Sun, 12 Mar 2017 12:33:44 -0700
X-Gmail-Original-Message-ID: <CAErg=HEC=YL-wWEygqtmivN0axZ_cddkM-WDc8RA+jVTJYmVgQ@mail.gmail.com>
Message-ID: <CAErg=HEC=YL-wWEygqtmivN0axZ_cddkM-WDc8RA+jVTJYmVgQ@mail.gmail.com>
To: Jacob Hoffman-Andrews <jsha@eff.org>
Content-Type: multipart/alternative; boundary="001a114b10365269e6054a8dacd8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/huJdZ5WuRpGixUi56cONyGDPdGY>
Cc: Patrick Donahue <pat@cloudflare.com>, Gervase Markham <gerv@mozilla.org>, Rob Stradling <rob.stradling@comodo.com>, Ryan Sleevi <ryan-ietf@sleevi.com>, "Salz, Rich" <rsalz@akamai.com>, Peter Bowen <pzb@amzn.com>, "spasm@ietf.org" <spasm@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.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: Sun, 12 Mar 2017 19:33:49 -0000

On Sun, Mar 12, 2017 at 11:06 AM, Jacob Hoffman-Andrews <jsha@eff.org>
wrote:
>
> Looking at the types of policy I described earlier:
>
> > 1. Policy set by user-facing domain owner for their own hostnames.
> > 2. Blanket policy set by CDN for hostnames they operate on their
> customers' behalf.
> > 3. Policy set by CDN for their own hostnames, which share the same
> base domain as the CNAME targets used in (2).
>
> In the tree-climbing world, given the above restriction on CNAMEs
> coexisting, it would be impossible for a CDN to express "(3) without
> (2)". Worse, if some CDN did express (3), it would be impossible for
> their customers to opt out by setting CAA records on their own domains.
> This would effectively bar CDNs from expressing (3) in the tree-climbing
> world.


> I think this is sufficient to say that tree climbing is undesirable.
> What do other folks think?


I think you're correct in that, in the absence of some form of trampoline -
and an 'any' policy - it can't be expressed.

However, am I mistaken in thinking that with those two - it could be? I
just want to make sure we know where the differences lie. Removing tree
climbing is arguably a substantive change to the specification, and would
likely require a document update. An 'any' expression and trampoline become
operational guidance, but don't require changing the specification.

Not to suggest one is more or less desirable than the other, but making
sure we've got a fully articulated set of guidance for "How you can
configure these cases with tree-climbing" and "How you can configure cases
without tree-climbing", and then evaluate their relative costs (to site
operators, to CAs, and 'process' wise). Does that sound reasonable?