[secdir] secdir review of draft-ietf-regext-rfc7484bis

["Scott G. Kelly" <[e-mail]>]

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