[lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 27 May 2019 23:18 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 340AA120019; Mon, 27 May 2019 16:18:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lamps-rfc6844bis@ietf.org, Russ Housley <housley@vigilsec.com>, lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155899913320.574.15070810245199939271.idtracker@ietfa.amsl.com>
Date: Mon, 27 May 2019 16:18:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/enOtOoM6l-m7EohrliD-0R1vsEg>
Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 27 May 2019 23:18:53 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc6844bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [updating to note that some of the content from Section 5.7 of draft-ietf-acme-caa may be worth mentioning in the security considerations of this document] Thanks for this helpful update! Section 2.2 I'm not entirely sure why we're going "backwards" from referencing STD13 to referencing RFCs 1034 and 1035 individually (in the definition of "Domain Name System"). Section 3 RelevantCAASet(domain): for domain is not ".": if CAA(domain) is not Empty: return CAA(domain) domain = Parent(domain) return Empty It would be nice to get an explicit note about whether this is intended to be pseudocode, Python code, etc.. Specifically, the "for domain is not '.'" syntax seems like it might be a more natural fit for a "while" construct. Section 4.3 issuewild properties MUST be ignored when processing a request for a Domain Name (that is, not a Wildcard Domain Name). I don't wish to revisit well-trodden ground (as I suspect this is), but note that the provided defitinions in Section 2.2 don't seem to exclude Wildcard Domain Names from being Domain Names, so that "that is" in the quoted text is not accurate. (In particular, note that the Wildcard Domain Name definition says that it is "a Domain Name consisting of [...]".) Section 4.5 The critical flag is intended to permit future versions of CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated Domain Names. It's not clear to me that the normative "MUST" is best, here. (Is anyone's behavior being constrained by this statement?) Section 5.1 An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRSet, irrespective of whether the corresponding DNS records are signed. I recognize that this is already the security considerations section, but this requirement introduces its own security considerations, namely that in cases where CAA responses received by the Issuer can be spoofed, there is an opportunity for denial of service. Section 5.4 does not seem to address this additional consideration relating to spoofing. Section 5.5 perhaps touches on it, but merely talks about "introduction" of a CAA RR, which may or may not imply the possibility of spoofing to an arbitrary reader. Use of DNSSEC allows an Issuer to acquire and archive a proof that they were authorized to issue certificates for the Domain Name. Verification of such archives MAY be an audit requirement to verify CAA record processing compliance. Publication of such archives MAY be a transparency requirement to verify CAA record processing compliance. Neither of these "MAY"s seem to be constraining the parties involved in this specification, which makes me wonder if they are more appropriate as ordinary "may"s. Section 5.4 Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls. Is "relied on" meant to imply "relied on as the sole source of DNS CAA information"? Section 8 Should the registration of the 'CAA' RRtype also be updated to refer to [this document]?
- [lamps] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [lamps] Benjamin Kaduk's No Objection on draf… Jacob Hoffman-Andrews
- Re: [lamps] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk