Re: [lamps] CAA Simplification draft

Roland Bracewell Shoemaker <roland@letsencrypt.org> Wed, 13 September 2017 01:29 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 08404133205 for <spasm@ietfa.amsl.com>; Tue, 12 Sep 2017 18:29:04 -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 IJfQUh-UUo4e for <spasm@ietfa.amsl.com>; Tue, 12 Sep 2017 18:29:02 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 E5109132F2E for <spasm@ietf.org>; Tue, 12 Sep 2017 18:29:01 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id y29so20490218pff.0 for <spasm@ietf.org>; Tue, 12 Sep 2017 18:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=0ICAfzF08ZFWYaWM35e7sipoMqILtJLxgQBiBAieyKc=; b=IlFEVv+UnEm1WwP7VhYxTvP5qpiWU2c/hGbpMMprVquifhuU4R+56h44X9IzqW6xno ToChbo8vHrs2CSLzBKNN073bsvv2aEIgNEnm7bn6eSXNiPvQPrhiSlk2ZbO9+pl1sgNv rIgxhLz2GVhNlRbBOcuXrfX5KwXa3lqgsZmjA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0ICAfzF08ZFWYaWM35e7sipoMqILtJLxgQBiBAieyKc=; b=fzrcR9OtwPvIneF7Gi1caWVVdWOcpaRZkoZADv/ENbFaQQozlD6p1YtpHpCcmsfoLi Bwy3KBE+R4F1R43v4cBAbOAoWJ1ZpcMBBg3tRIctWmy4O0yvrPWXFtfZPC2uQqb+L+gu K45hMsBgUTiezci6smkZL4jaK81TiaeDX+G91jE0/e75NCXLlsMSZDlUvawyz1e4tn5P RhvUA3NPxOTkAdxMvILeb0NQanCI4LpQgC1fZ3de53wb6pRuwNsF53nZZnD4u6HZzECp NggfIZQnyP+3wBLAXn28pMVrfGg6+5WtVNH4wcOvvLhK6Ro+T3v9rEM0MH8gM8ByUfZU nuyA==
X-Gm-Message-State: AHPjjUgauMaox5Zk+btKWZ7AwN2HjD0trtmoGNXDY3gAvyz899HkBx0C hgpC67sCBZpCWi7oQ/L0WQ==
X-Google-Smtp-Source: ADKCNb7J9rRIEWBxMb2v74pPkBp88bFOdASOTCtUIayBVZVkG2+YyIT9g5JtcJSESC8qjVrQN48DAA==
X-Received: by 10.98.86.73 with SMTP id k70mr16278368pfb.345.1505266141156; Tue, 12 Sep 2017 18:29:01 -0700 (PDT)
Received: from [192.168.42.99] ([50.1.57.72]) by smtp.gmail.com with ESMTPSA id v31sm20114386pgn.43.2017.09.12.18.29.00 for <spasm@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 18:29:00 -0700 (PDT)
To: spasm@ietf.org
References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org>
From: Roland Bracewell Shoemaker <roland@letsencrypt.org>
Message-ID: <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org>
Date: Tue, 12 Sep 2017 18:28:59 -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: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.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/kLwvgDMg2e9inrvHH3-lbIF6evw>
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 01:29:04 -0000

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.

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
>