Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-add-ddr-08

Lars Eggert <> Tue, 12 July 2022 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CB2FC14F72B; Tue, 12 Jul 2022 13:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R215vVv-hZ1s; Tue, 12 Jul 2022 13:34:46 -0700 (PDT)
Received: from ( [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34032C14F606; Tue, 12 Jul 2022 13:34:46 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 50F5F1D374B; Tue, 12 Jul 2022 23:34:35 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1657658076; bh=CFB9dSt3dcziln3aNFyUBHrRvnR3sUtQtdbtmd+5EQM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=AoICWHhgDJcwm7+wg8lvms3ii8kwAIJQoPx7Y9Tpgz8hFeUYRfNRwDvk2sv8ggxHB n3EvweZHcdXT0FnQdjfdAGPosQaN82c8ES45fYYdKKdlXr7O4nmOenL/bOLiXjXQin TRJLkkBGsQIb0JXBn2AGB+suknzbN8grqN1q1lh4=
Content-Type: multipart/signed; boundary="Apple-Mail=_50D383E2-BCF5-4F4E-A146-64BDBD8EF043"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Lars Eggert <>
In-Reply-To: <>
Date: Tue, 12 Jul 2022 13:34:32 -0700
Message-Id: <>
References: <>
To: Robert Sparks <>
X-MailScanner-ID: 50F5F1D374B.A99DC
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
Archived-At: <>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-add-ddr-08
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2022 20:34:50 -0000

Robert, thank you for your review. I have entered a No Objection ballot for this document.

Authors, please also take Robert's comments into consideration for your next revision.


> On 2022-7-8, at 9:19, Robert Sparks via Datatracker <> wrote:
> Reviewer: Robert Sparks
> Review result: Almost Ready
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-add-ddr-08
> Reviewer: Robert Sparks
> Review Date: 2022-07-08
> IETF LC End Date: 2022-07-08
> IESG Telechat date: 2022-07-14
> Summary: Has issues to address before publication as a Proposed Standard RFC
> (Note: I reviewed -07, and noticed -08 while entering this review. I've read
> the diffs, and believe all the below to still be relevant).
> Issues:
> RFC 6761 requires explicit discussion of seven categories of consumers of a new
> SUDN. This document does not yet provide that discussion.
> There's a lack of discussion of issues around certificate revocation throughout
> the document. The end of section 4.1.1, for example, cuts off an mitigation
> opportunity should control of a certificate used by the Designated Resolver be
> lost.
> Please add an explanation for _why_ the requirement in the last sentence of the
> first paragraph of 4.2 exists. As written, it seems out of context, and
> underspecified (which SVBC result, obtained when, should the client consider
> the TTL from?).
> The discussion of providing differentiated behavior over unencrypted DNS is
> good to call out, but needs more depth. There are many other fields an attacker
> might modify, even outside the DNS part of the datagram (say, the source IP
> address) that could give the attacker an advantage if the returned results
> varied.
> Nits:
> In the introduction, please reconsider "claims ownership over the IP
> addresses". It would be better to simply say "contains the IP addresses in the
> SubjectAltName.
> There is tension between the normative SHOULD NOT and SHOULD in the first
> paragraph of 4.1.1 and the SHOULD in the first paragraph of 4.2. Please clarify
> the wording in one place or the other so that an implementer isn't forced to
> violate one of those normative requirements to satisfy the other.
> The last sentence of the first paragraph of 4.3 is imprecise. It would address
> my discomfort to replace "cannot be confirmed" with "cannot be safely
> confirmed", or add a pointer to a description somewhere else about why trying
> to include such addresses in a certificate is an unworkable idea.
> At the end of the second paragraph of 4.3, consider future protocols that might
> use something other than TLS as the security layer. The sentence as is takes a
> shortcut past the point your are really trying to make.
> The use of SHOULD in the second paragraph of section 5 is strange. Do you mean
> "are expected to be"? The other side of this coin (that records are NOT
> expected to be present) isn't obvious to find in section 4.
> Consider explicitly calling out what the implementation MUST do if the
> validation in the 4th paragraph of section 7 fails.
> (Feel free to ignore this, but): At the 5th paragraph of section 7, consider
> discussing the risks of an operator running an Unencrypted Resolver at a given
> IP and _not_ running a Designated Resolver there. This adds an attack point for
> an adversary to gain enough access to run their own Designated Resolver there,
> even if they can't gain enough privilege to affect the Unencrypted Resolver.
> Micro-Nits:
> Section 3 3rd to last paragraph: s/use others records/use other records/
> --
> last-call mailing list