[Acme] Dnsdir telechat review of draft-ietf-acme-integrations-13

Ted Lemon via Datatracker <noreply@ietf.org> Wed, 01 March 2023 12:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: acme@ietf.org
Delivered-To: acme@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD5C15170B; Wed, 1 Mar 2023 04:59:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ted Lemon via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
Cc: acme@ietf.org, draft-ietf-acme-integrations.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167767556087.4986.15874948037371201373@ietfa.amsl.com>
Reply-To: Ted Lemon <mellon@fugue.com>
Date: Wed, 01 Mar 2023 04:59:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/SSaDbU6x7YItX1zofU0vih2NeM4>
Subject: [Acme] Dnsdir telechat review of draft-ietf-acme-integrations-13
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2023 12:59:20 -0000

Reviewer: Ted Lemon
Review result: Ready

In my previous review, I mentioned that the text about graph theory seemed to
make the document harder, not easier, to understand. This was an editorial
comment, which the authors mostly ignored, which is fine. They did add an
admonition to the reader to read RFC8499 for further clarification, for what
that's worth.

I also mentioned that the diagrams that show the ACME process aren't
contextualized as being part of ACME, which made it hard to figure out where
these operations were actually described in a standard.  The authors added some
text that may have been intended to address this concern, but it's not clear,
and I don't think this suggestion has been addressed. It was an editorial nit,
so that seems like a reasonable, if disappointing, reaction.

I also mentioned that the text about the use of ACME for subdomains is somewhat
contradictory, since in one place it says they are not necessary, and in
another case it gives an example that depends on them. Some text has been added
that may have been intended to ameliorate this concern. This was a "ready with
issues" point, meaning that I thought it should definitely be corrected. I
think this change addresses the concern.

I also asked for a clarification in the security considerations section (now
section 10) that the mention of using DNS updates and TSIG or SIG(0) was
needlessly prescriptive. The update softens this text and I think addresses my
concern.

I also pointed out an issue with the text implying that TSIG uses "DNS key
records," which it does not, and the new text no longer confuses key records
(SIG(0)) and TSIG keys, referring to both as "credentials." This addresses my
concern, and also includes other means of update in the concern about
credential leakage. I think this addresses my concern.

I further requested that references be given for RFC2136 and RFC2931 since the
mechanisms described therein were being referenced. These references have been
added.

So I would say at this point that the concerns I raised have been addressed and
the document is ready to go.