Last Call Review of draft-ietf-regext-rdap-reverse-search-23
review-ietf-regext-rdap-reverse-search-23-secdir-lc-kivinen-2023-08-08-00
| Request | Review of | draft-ietf-regext-rdap-reverse-search |
|---|---|---|
| Requested revision | No specific revision (document currently at 26) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2023-08-11 | |
| Requested | 2023-07-28 | |
| Authors | Mario Loffredo , Maurizio Martinelli | |
| I-D last updated | 2023-08-08 | |
| Completed reviews |
Artart Last Call review of -23
by Scott Hollenbeck
(diff)
Opsdir Last Call review of -24 by Tim Chown (diff) Genart Last Call review of -24 by Susan Hares (diff) Secdir Last Call review of -23 by Tero Kivinen (diff) |
|
| Assignment | Reviewer | Tero Kivinen |
| State | Completed | |
| Request | Last Call review on draft-ietf-regext-rdap-reverse-search by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/0Y8NxDpR012Ibuq-LQ5ZBu2K1sQ | |
| Reviewed revision | 23 (document currently at 26) | |
| Result | Ready | |
| Completed | 2023-08-08 |
review-ietf-regext-rdap-reverse-search-23-secdir-lc-kivinen-2023-08-08-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. This document describes the reverse search method for RDAP protocol. It does include implementation considerations, privacy considerations in addition security considerations, which do list number of issues that the implementations need to solve. Including limiting number of resources returned, protecting Personally Identifiable Information, and methods of doing authentication. It does require HTTPS because of the privacy concerns, but authentication and authorization is only SHOULD: In general, given the sensitivity of this functionality, it SHOULD be accessible to authorized users only, and for specific use cases only. This SHOULD does not list reason when it would be ok to provide this information without authorization. I would assume one such use case would be when there is no PII or sensitive information in the database...