Last Call Review of draft-ietf-regext-rdap-redacted-14
review-ietf-regext-rdap-redacted-14-secdir-lc-orman-2023-09-11-00

 	                Security review of 
Redacted Fields in the Registration Data Access Protocol (RDAP) Response
		draft-ietf-regext-rdap-redacted-14

Do not be alarmed.  I generated this review of 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
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

The Registration Data Access Protocol carries information about DNS
registrants.  The server might choose to withhold some data based on
its access policies, particularly for privacy.  This document
describes a redaction method in which the server explicitly states in
the response which data fields or data values were redacted.

The method has a clear disadvantage mentioned in the security
considerations: it can leak field identifiers that might not apply to
all users.  For private information, this can have serious
implications.  The security considerations offer the option to simply
omit, without note, fields that are sensitive.  This might be done if
the provider wants to conceal the sorts of metadata that it keeps
about users, but concealment should be done for sensitive information
(e.g., "criminal record", "amex credit card", etc. [silly examples
used for illustrative purposes]).

Transparency would require the server to have a published policy
saying which data is sensitive and whether or not it will be
explicitly redacted or silently omitted.  Note that if the data
structure is publicly known, then silent omission is pointless.

There are some issues about information flow that should be carefully
considered when writing such a policy.  For example, I assume that it
is obvious that if the server has an empty field, then that
information is still redacted if the policy is "redact".

I think that the security consideration section needs amplification
in light of the possibility of leaking sensitive data.

Hilarie