Last Call Review of draft-ietf-regext-rdap-object-tag-04

Request Review of draft-ietf-regext-rdap-object-tag
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-06-19
Requested 2018-06-05
Authors Scott Hollenbeck, Andrew Newton
Draft last updated 2018-08-01
Completed reviews Secdir Last Call review of -04 by Taylor Yu (diff)
Genart Last Call review of -03 by Roni Even (diff)
Opsdir Last Call review of -03 by Tim Chown (diff)
Assignment Reviewer Taylor Yu 
State Completed
Review review-ietf-regext-rdap-object-tag-04-secdir-lc-yu-2018-08-01
Reviewed rev. 04 (document currently at 05)
Review result Has Nits
Review completed: 2018-08-01


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 Ready with nits.

I agree with Ben Kaduk's comment:

> Section 7
> Perhaps note that it is using IANA as a well-known central trusted
> authority in order to provide the property of allowing users to get RDAP
> data from an authoritative source?
>    [...] The method has the same security
>    properties as the RDAP protocols themselves.  The transport used to
>    access the IANA registries can be more secure by using TLS [RFC5246],
>    which IANA supports.
> Well, I don't know that "the same as" is quite right, especially given the
> following sentence.  The composed chain of "talk to iana, talk to referred
> RDAP server" depends both on the security of the connection to the RDAP
> server and that of the connection to IANA; it seems prudent to note that if
> TLS is used for the RDAP connection, TLS should also be used when talking
> to IANA, or even that TLS should always be used when talking to IANA.

There is also the issue of trust anchors when using TLS.  The normative
references also do not mention this issue, so maybe it is out of scope
to deal with it here.

Best regards,