Re: [lamps] CAA Simplification draft

Roland Bracewell Shoemaker <roland@letsencrypt.org> Wed, 13 September 2017 05:56 UTC

Return-Path: <roland@letsencrypt.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 E6F23132026 for <spasm@ietfa.amsl.com>; Tue, 12 Sep 2017 22:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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=letsencrypt.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 a9P6BfszWSNC for <spasm@ietfa.amsl.com>; Tue, 12 Sep 2017 22:56:14 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 635AB1321D8 for <spasm@ietf.org>; Tue, 12 Sep 2017 22:56:14 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id e199so22039438pfh.3 for <spasm@ietf.org>; Tue, 12 Sep 2017 22:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FxMhnmx2Zar5BQkEkzU+Z31ksQGCqliWKKHLg/PGnS0=; b=BzOLh9Z0o2PYaIMLWmJfNVMZFlzRIdKAGpIU5ICdxMY6AfVq0CE0kXT0L+badd4C/l ty2qSJ2+XWgVpuE12z+7g8+K2AMiMetLPsKbSn4fYmuc/54sm0/EqXhB60xng9pzvNDq 5FTsaHZrVtPazj+hYen5sgKF0219zs0VhMXec=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FxMhnmx2Zar5BQkEkzU+Z31ksQGCqliWKKHLg/PGnS0=; b=NIihEb3epYq0Ph+PDk+m4tEGgP+efVoNDvKwddUF9hFJG3uOvAkdtFWwxM2O9oc+Kc YuixUYCMLYyUt8mPsObXbmzpTdSEyDimZWprzhTEmWlpVTaeTH7TADR434SC2tGD5G1p T0xw1yNoo+IBO4htADiJUMdJaRawFKuO7p8M4zYAkydcPekI6K7Hi+9ucJrFPLHLgWG/ 2cq3FiWXbeTyVfZoZf3ruF7oR+Vq56eah4Vs4XMhWNh22KC3gM0sanHzl4ig5Gaeoqbz MqHRcAeYwcBm6/3NwLHAK2W7ggi2h0X0qXDL5LnPkIUI+vZRt+vpLwPvYybtWuJRATzh h/aw==
X-Gm-Message-State: AHPjjUiXAKuDiwanxPQ1i4wCIHL60HtfPPYeanChwg+Zi7mHc83ID9N5 ejUEtZC4dKexUkZzt/KlLw==
X-Google-Smtp-Source: ADKCNb64wOOqATqKmezSd+sgiGjAaEYX7gt0+oZCp8C7+6DUESEWSaUb/oU5j4tQygDSOoz9X7WwWg==
X-Received: by 10.98.15.208 with SMTP id 77mr17135032pfp.318.1505282173601; Tue, 12 Sep 2017 22:56:13 -0700 (PDT)
Received: from [192.168.42.99] ([50.1.57.72]) by smtp.gmail.com with ESMTPSA id x9sm23938762pfk.40.2017.09.12.22.56.12 for <spasm@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 22:56:12 -0700 (PDT)
From: Roland Bracewell Shoemaker <roland@letsencrypt.org>
To: spasm@ietf.org
References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org>
Message-ID: <54f6a03b-17cd-de4f-de3c-5a3cf8c14afa@letsencrypt.org>
Date: Tue, 12 Sep 2017 22:56:11 -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: <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/8Nv48s6gGosb3bnH7N9c59RHX64>
Subject: Re: [lamps] CAA Simplification draft
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, 13 Sep 2017 05:56:17 -0000

On 09/12/2017 06:28 PM, Roland Bracewell Shoemaker wrote:
> While this removes the ambiguities with regard to CNAME and DNAME alias
> handling I think the definition of the algorithm is still unnecessarily
> hard to read. Also references to 'CNAME' should be replaced with
> 'aliases' since 1034 section 4.3.2 as updated by 6672 also handles
> DNAMEs (although to be honest I think any references to specific 1034
> 4.3.2 behavior can just be removed since they are incorporated simply by
> referencing that algorithm).
> 
> I'd suggest that Section 4 paragraphs 3-9 be replaced with the following
> cleaned up definition using pseudocode and a better explanation of the
> steps the algorithm uses in the example:
> 
> https://github.com/jsha/caa-simplification/compare/master...rolandshoemaker:alg-cleanup?expand=1
> 
> I'd also recommend this RFC be paired down to only section 4 since that
> is all that is being changed and make it a 'Updates' instead of
> 'Obsoletes' style RFC that just redefines the lookup algorithm.

I'll actually retract this after reading through RFC 2223 and 7322,
since this is a breaking change from the algorithm in 6844 this should
probably be a 'Obsoletes' and therefore contain all of the existing
content that isn't being changed.

> 
> Thanks for doing the work on this! I think taking this approach, of
> simplifying the algorithm definition, is better as completely
> re-designing the algorithm and using a different record style,
> especially given this is what CABF has already adopted, without a well
> defined reason is just asking for more problems down the line.
> 
> On 09/12/2017 05:23 PM, Jacob Hoffman-Andrews wrote:
>> Hi all,
>>
>> This is a revision to RFC6844 as discussed previously on the list and at
>> IETF 99. In particular, RFC6844 specifies that CAs should implement
>> "tree climbing" not only on the original FQDN, but also on any
>> intermediate CNAMEs discovered during primary lookup. As discussed
>> on-list, this disallows certain deployment scenarios, and can produce
>> surprising results in common CNAME-based hosting scenarios.
>>
>> Additionally, because RFC6844 re-specified parts of CNAME lookup, some
>> details were ambiguous. This draft updates RFC6844 to eliminate tree
>> climbing on CNAME targets, and to reference RFC 1034 for the standard
>> DNS lookup algorithm, including CNAME resolution.
>>
>> Because all of this draft is the same as RFC6884 except for the
>> "Certification Authority Processing" section, I've retained the original
>> two authors and added my own name. Please let me know if IETF etiquette
>> indicates a different approach.
>>
>> I'd like to propose this draft for adoption by the WG.
>>
>> https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt
>>
>> Thanks,
>> Jacob
>>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>>