Subject: [secdir] Secdir review of draft-ietf-drip-rid-07

From: Magnus Nyström <[email-masked]>
Date: Fri, 23 Jul 2021 22:14:29 -0700

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 26 Jul 2021 13:52:53 -0400

Magnus,

Thank you for your comments.  I have been with minimal connectivity due 
to storm induced power outage.

I did push out ver 08.  I quick read through your comments show I fixed 
other stuff.

I will go over your comments and get with CFRG (and about some light 
crypto stuff) in the coming weeks.

Bob

On 7/24/21 1:14 AM, Magnus Nyström wrote:
> 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).
>
> 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.
>
> 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.
>
> 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" 
> 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.
>