Re: [lamps] New draft: rfc6844bis

Jacob Hoffman-Andrews <jsha@eff.org> Tue, 17 July 2018 22:45 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 B59C7130F1D for <spasm@ietfa.amsl.com>; Tue, 17 Jul 2018 15:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 iolZDcHSJyTk for <spasm@ietfa.amsl.com>; Tue, 17 Jul 2018 15:45:29 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B217130DF4 for <spasm@ietf.org>; Tue, 17 Jul 2018 15:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qSCfzx7vncWWjAg3iVXz/KfZGRpYcKoA7SLNz4FSAZo=; b=HMdPKSOHpfq82DziPPP5Ix3iPX fPK3EFQpm6ajI+InrddTiCoXesm3FZsiplrO7F0s7vWfC1KRYPnUzQtvIzHddGGAYzsG2diXP+ggF eG6SW9kvLTbXSf9Z2IaJgW6FEQhoRxCPfca9Upk1SIx1imOXC6hp7eAhJYwmjgmx0voE=;
Received: ; Tue, 17 Jul 2018 15:45:28 -0700
To: Corey Bonnell <CBonnell@trustwave.com>, SPASM <spasm@ietf.org>
References: <d25080b7-d21c-219e-8d99-7c19afb5b30f@eff.org> <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <171ce08e-3700-45e8-8208-08bb15077f72@eff.org>
Date: Tue, 17 Jul 2018 15:45:28 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/olbJ2UfaTCnJcuKL9RlNsKTQOuU>
Subject: Re: [lamps] New draft: rfc6844bis
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 17 Jul 2018 22:45:32 -0000

On 07/10/2018 06:58 AM, Corey Bonnell wrote:
> It looks like the updated ABNF grammar for the issue property tag is missing some line breaks, as several of the production rules are now on the same line.
Thanks. I've fixed this in my working copy, and it will make it into the 
next revision.

> There is one more issue that we might want to tackle as part of the 6844-bis effort: changing the "SHOULD" for making CAA queries against authoritative nameservers to a "MUST" (section 6.3: For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server). This was originally mentioned in https://blog.cloudflare.com/caa-of-the-wild/, but I don't think this has been brought up on this mailing list before and thought we should at least discuss it. My opinion is that it should remain a "SHOULD" in the RFC, otherwise the RFC is dictating policy. The preferable route is to define required lookup properties in policy explicitly (eg, the Baseline Requirements would dictate that all lookups MUST be performed against an authoritative nameserver).
Yeah, I agree we should keep this as a SHOULD. I think defining what 
exactly it means could get messy. For instance, CAs are likely to use an 
internal recursive resolver, which in turn contacts a series of 
authoritative resolvers.