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. Lars > On 2022-7-8, at 9:19, Robert Sparks via Datatracker <noreply@xxxxxxxx> 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 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 > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
