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 comments.

This document describes the use of "Hierarchical Host Identity Tags" as
self-asserting IPv6 addresses and thereby trustable identifiers for use as
Remote IDs.

As the security of HHITs to a large degree relies on the security of the
cryptographic constructs and primitives described in this document, I would
recommend that the IRTF CFRG or a similar group with cryptographic
expertise reviews this memo (unless it has already been done).

The security of the HHITs also seem to depend to a large degree on the
registrars (registry operators) that will act as backstops to ensure no
duplicate registrations etc. It might be helpful with a clear statement as
to the conditions that must be met by registrars in order for this scheme
to be secure.

As noted, the use of a 64-bit hash is weak when considering pre-image
attacks. I do not understand the constraints the authors have been working
under in this context enough to say if there was an option for a longer
hash, but I think this should be part of the above suggested CFRG review.

The text "Another mitigation of HHIT hijacking is if the HI owner (UA)
supplies an object containing the HHIT and signed by the HI private key of
the HDA such as Appendix E.1
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#appendix-E.1> as
shown in Section 3.5"
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.5>
confuses me a bit since I don't see how the subject of an attack would be
able to tell should the HHIT hijack attempt occur before the HI owner has
supplied such an object?

Lastly, the statement "The authors believe that the probability of such an
attack is low when Registry operators are using best practices" seems weak
and would preferably be backed with some more quantitative analysis or at
least specific statements around best practices and how they would reduce
the probability.

Editorial: The document is in need of a grammar / wording polish but I
expect the rfc-editors to handle this.

Thanks,
-- Magnus