Last Call Review of draft-ietf-regext-rfc7484bis-04
review-ietf-regext-rfc7484bis-04-secdir-lc-kelly-2021-12-02-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is almost ready

This review is quite late, but still ahead of the telechat, so I hope it is
useful.

From the abstract:
   This document specifies a method to find which Registration Data
   Access Protocol (RDAP) server is authoritative to answer queries for
   a requested scope, such as domain names, IP addresses, or Autonomous
   System numbers.  This document obsoletes RFC7484

Here is the security considerations section:

   "By providing a bootstrap method to find RDAP servers, this document
   helps to ensure that the end users will get the RDAP data from an
   authoritative source, instead of from rogue sources.  The method has
   the same security properties as the RDAP protocols themselves.  The
   transport used to access the registries can be more secure by using
   TLS [RFC8446], which IANA supports.

   Additional considerations on using RDAP are described in [RFC7481]."

Because this document is updating RFC7484, and because these security
considerations are copied verbatim from that doc, I hesitate to raise my
concern. Nonetheless, I think the assertion that this document "helps to ensure
that the end users will get the RDAP data from an authoritative source, instead
of from rogue sources." is questionable. I think the suggestion to use TLS
helps, but I think it would be better to say something like this:

"This document specifies a method to find which RDAP server is authoritative to
answer queries for a requested scope, such as domain names, IP addresses, or
Autonomous System numbers. If this data is not authenticated, an adversary may
inject data that redirects the user to a rogue RDAP server. A robust
authentication method such as may be provided by TLS [RFC8446] SHOULD be
utilized to protect against this.

Additional considerations on using RDAP are described in [RFC7481]."

I'm not attached to the precise wording, but I think implementers should be
told what the risks are, and how to mitigate them. I don't think the current
security considerations quite hit that aspiration.

--Scott