Re: [lamps] CAA tree climbing, gurrghhg

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 07 October 2017 17:30 UTC

Return-Path: <hallam@gmail.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 22BE31331D2 for <spasm@ietfa.amsl.com>; Sat, 7 Oct 2017 10:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 6PJccBxIpJzV for <spasm@ietfa.amsl.com>; Sat, 7 Oct 2017 10:30:36 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 442F4134A28 for <spasm@ietf.org>; Sat, 7 Oct 2017 10:30:36 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id v9so21823476oif.13 for <spasm@ietf.org>; Sat, 07 Oct 2017 10:30:36 -0700 (PDT)
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:cc; bh=DBiO7iE0FdwDm/nD0mZ/8nkN8SYlW85TceqkDkP7xgs=; b=HVljZLx1A2HuMQErZvR92JCnV0D9vKBB20dgyym7KwpPZ2WMLxC3W8o8gOo7ZRLXoj 5+mbIbLnVVn3KsjI6xMjaCqDLu4Ide/U/nhCbxRjN0n1tx0+Abqxuj4HFCzBpv0APT2o KXtTbWSWSejlCRvtU5imROoDfvdIAdOkQ0M21yv6f8yWozJ3ozzBflODyVJeDAj7oNYy 31mF1lHcLlvnj6dXRKUR3MqzlRvOLRwINDxewtRqhLAEL5yA9mW2b9neBP1wrJsZpwoe vsQHjC6xQXUDWggk/V93AW+LAL9qj/RbVgueArUR7CZHMVpfoIxK8RY1dU0qnhoD2YOI dLRg==
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:cc; bh=DBiO7iE0FdwDm/nD0mZ/8nkN8SYlW85TceqkDkP7xgs=; b=PngK280vnbNiMbcHPNpt0izXtD0fPukDJAq0EcpMut8D2hEXanMrtd//EtDHWiZegJ 1q0H6FZ6xAdePX3vp5sjEwM9KpN8OnOQgzW8o/coUuYxQ+sZqjmv5BhvaZm2/fM33+SD QEER3letWR52X7qNmLDUUF/K/22PWF50s0nHrv3wZdcR0kD6Ur3miOmz9Brmp2tK2+hr GjknJEslmnN9uOQMuwtlrRryUwwW9fDrI/UsnSCAAGIeWUJQLasNVo4qBBsVud+jV5Ne Enujds+9o8D+alx0NHhp6JDCvcZ8DGZiGJ8V7bTX7SPvUQDL/ki+4kGvwzTKjstB+Lk/ fjkQ==
X-Gm-Message-State: AMCzsaUvpZHU86Il1yUcVbAnHBw73130FN35uJv3cv1+R+qiDintGeFM lLpwRm6xyTz6b91KaR+/Bsl+pD1S+N/LYT4NGJc=
X-Google-Smtp-Source: AOwi7QAmKe73h5baT0nhg7k6koem/1DqPk0f28FHSti8KkaunIXKdYsC0sDOdZw2wzwmq7i7BD3IXCOQkiHb/Ovw/PI=
X-Received: by 10.202.195.212 with SMTP id t203mr3066818oif.279.1507397435540; Sat, 07 Oct 2017 10:30:35 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.95.12 with HTTP; Sat, 7 Oct 2017 10:30:34 -0700 (PDT)
In-Reply-To: <CAErg=HGZeWRM51PD28KoZR+AE4CKVvoC-JgQg3BQu_fE_6iaAg@mail.gmail.com>
References: <CACh0qC+jRjPMsf7YmDqoKZ0X1zWE2p=fUAo5uN3bZwwzBRG9Kg@mail.gmail.com> <alpine.OSX.2.21.1710061656080.33175@ary.qy> <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> <alpine.OSX.2.21.1710061814390.33785@ary.qy> <CAMm+LwhiPhqQbfhHHaZZ6aoA5WS=FZ5q+ETtC4CLA_OWirgrhw@mail.gmail.com> <alpine.OSX.2.21.1710071101400.36268@ary.qy> <CAErg=HGZeWRM51PD28KoZR+AE4CKVvoC-JgQg3BQu_fE_6iaAg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 07 Oct 2017 13:30:34 -0400
X-Google-Sender-Auth: fAO3E82tRIFjZ7sOEwSNMjZhym0
Message-ID: <CAMm+Lwi7nSSTxNkCACHb5hgepzH9v3qRtbjOmWru9M=Q7aWecw@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: John R Levine <johnl@taugh.com>, SPASM <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="001a1134fdeaae4fa3055af85013"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/QlR_Bl5PGGeeE9liY_7Vbqu0C84>
Subject: Re: [lamps] CAA tree climbing, gurrghhg
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: Sat, 07 Oct 2017 17:30:38 -0000

On Sat, Oct 7, 2017 at 12:24 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

>
>
> On Sat, Oct 7, 2017 at 11:09 AM, John R Levine <johnl@taugh.com> wrote:
>
>> One side effect of that is that there cannot be any loose ends. PSL is a
>>> loose end.
>>>
>>
>> Perhaps, but CAs already use it a zillion times a minute to decide what
>> certs to issue.
>>
>> We debated the dbound problem at great length and then decided that it
>>> doesn't matter. There are really only a few TLDs of any consequence and
>>> if
>>> they did something silly, we can vote to unsilly as a special case. And
>>> since they know that, it is unlikely folk will be silly.
>>>
>>
>> It would not be silly for Verisign to put a CAA at com. saying it has no
>> certs at all.  But it would be extremely silly for CAs to apply that CAA to
>> 2LDs or 3LDs under .com.
>>
>
> I don't think that's the same meaning. I think, especially in the world of
> gTLDs, it's both reasonable and sensible to allow CAA records at the TLD,
> and there's no need for the public suffix list concerns. At best, such
> problems are business problems - not technology problems.
>

​My original proposal was that CAs were required to state what their CAA
policy was. This could range from ignore completely to enforce exactly. I
deliberately left that slack in the system because the alternative was to
deal with all the implications of ICANN world in IETF.

The stick there was that any CA that mis-issued was going to find
themselves on a very sticky wicket if they had not checked CAA. Contrawise
if the subject had not issued a CAA record then they would be at fault.

The problem with that approach was that there is a network effect. There is
little value in publishing CAA until it is checked and vice versa. Hence
the need for CABForum to make it mandatory.

Given that we have CT, we could have a scheme in which a CA may use any
domain exclusion list provided that they publish it in a CT log first.​ But
that seems like something more in 'policy' space than 'technical'.