[Drip] AD review of draft-ietf-drip-rid

["Eric Vyncke (evyncke)" <[e-mail]>]

Hi,



Thanks to the authors, shepherd, and the DRIP WG for producing this 3rd I-D. And, I appreciate that the comments from iotdir, secdir, cfrg, .. were taken into accounts :-)



As usual, here is my AD review before going to the IETF Last Call and continuing the publication process. Except noted by a "***", all the comments can be ignored but I would appreciate a reply telling "we have read your comment but prefer to ignore" (or a variation of this text).



I hope this helps improving the document and ease the publication process.



Regards



-éric



---- review below



# Generic

Just curious, should the drip-arch document be mentioned somewhere ? E.g., in section 1



The text is really not consistent of using "HHIT" vs. "Hierarchical HIT" or "DET" vs "USA Remote ID DET" ... This does not help reading and understanding.



# Abstract

s/ (e.g., DNS, EPP)/ (via, e.g., DNS, EPP)/ ?



# Sect 1:

"Unmanned Aircraft System Remote Identification and tracking (UAS ID)" but RFC 9153 says " UAS ID UAS identifier.". Suggest being consistent and/or explain what the difference is.



Moreover, RFC 9153 has text about "DRIP identifier" and not about "UAD ID".



Please expand HIT and HIP at first use.



The discussion about PKI and X.509 certificate appears from nowhere, suggest having sub-section somewhere with justification of HHIT



# Sect 2.3:

s/ HDA (Hierarchical HIT Domain Authority)/ HDA (HHIT Domain Authority)/ ?



When defining HIP please add a reference to RFC.



# Sect 3

In figure 1, some early explanations about "orchid hash" would be welcome.



The text mention "context ID" but should it be "Orchid context ID" since IANA registry is about "CGA Type Tags" ? At least, a link to ORCHID should be given.



*** "A script for generating HHITs based on an early version of this specification is available at [hhit-gen].", it makes little sense to have an implementation of an outdated specification. Moreover, the link is 404 on github.



# Sec 3.1

Sometimes it is "HIP" and here it is "HIPv2", let's be consistent.



# Sec 3.2.1

Should the column heading be "HHIT Suite" rather than "HIT Suite" ?



"HDA Assigned" is rather unusual, why not using "experimental" or "private use" as it is often the case in other IANA registries ?



# Sec 3.3.1

As RAA has a length of 14 bit, I wonder what is the meaning of " RAA should be allocated in blocks with consideration on the likely size of a particular usage"



*** It is also unclear who allocates the RAA ? If IANA, then this should be in the IANA section. Else, please describe how colliding RAA are resolved/detected. I understand the registry I-D is coming but it is really puzzling for the reader. Did the author consider moving parts of the registry I-D in this section ? After all, it is more about the HHIT structure than registries interactions.



Which is " This DNS zone" ?



Should "100" rather be "decimal 100" ?



Should this be a "SHOULD" or even a "MUST" in "The PTR record could be constructed" ?



*** Even the registry I-D does not mention this PTR record and does not specify which party will own the "hhit.arpa" zone.



# Sec 3.3.2

It is useless to expand RVS as it has been done before.



s/RVS servers/RVSs/ ?



# Sec 3.4

Should "-Curve" be also in the section title ?



"HI" was already expanded before.



# Sec 3.5

The last sentence is about "addendum", are we sure that this I-D does not need to formally update ORCHID ?



# Sec 3.5.1

" This addendum will be constructed as follows": this is rather obscure.... What about something like "This document specifies another way to compute ORCHID".



Suggest using the same wording (e.g., for "Prefix") as in ORCHID.



Be clear that " p + n + o + m = 128 bits" is a MUST.



# Sec 3.5.2

Again "addendum" which is rather vague in an I-D.



" The cSHAKE function call for this addendum is" or should it be " The cSHAKE parameters for this addendum is"



# Sec 3.5.2.1 and 3.5.3 and 3.5.4

*** What is the intent of these sections ? It smells like it is really an argument to formally update ORCHID.



# Sec 4

Should the section title be " Hierarchical HITs as DRIP Entity Tags" ?



What is the purpose of the first paragraph ? It has already been said before.



" This hierarchy, cryptographically embedded within the HHIT, provides the information for finding the UA's HHIT registry", is it really "cryptographically embedded" ?



Is the ASTM part useful in this document ? I cannot see the link with DET.



# Sec 4.2

*** Please provide a normative reference to base32.



The discussion about not using base34 may be skipped IMHO.



*** " A mapping service (e.g., DNS) MUST provide a trusted" is really hand waving and I am unsure how DNS could be use there. How useful is this spec if there is no mapping ? Should this be a IANA registry ?



# Sec 4.5

The 2nd paragraph is nice but should perhaps be moved in the RAA section ?



# Sec 4.6

*** What is " ASTM Authentication Message" (at least provide some references).



# Sec 5

" The following are examples of how this may be done".... and this I-D is assumed to be standard track. I.e., it should either use normative language or be removed IMHO (as it is probably better in the registries I-D).



Should 100 and 50 be prefixed by "decimal" ?



s/ following: Assume/ following: assume/



" A secure connection (e.g., DNS-over-TLS [RFC7858]) to the authoritative zone may be a viable alternative to DNSSEC." But I wonder whether the authoritative servers (and not zone BTW) will be happy with the load...



The "ipv6.arpa" example is missing the value for the PTR RR.



# Sec 6 and 7

Unsure whether these 2 small sections belong to this document. Suggest to remove them.



# Sec 8

At the authors' discretion, this section could become part of the security considerations (and it could also be renamed in 'Privacy Considerations')



" through address randomization", which address ? MAC ?



Please explain what "PHY" and "C2" are ;-)



In " Simply changing the UAS RID" should this rather be DET ?



# Sect 9.5:



Should it be before section 9.1 as if request the allocation of /28 to be used in section 9.1 ?



" DRIP Device Entity Tags" ? or " DRIP Entity Tags" ?



# Sec 10

*** Please provide a reference to "a Python script"



About the " *single* bitcoin mining ASIC", it is about the sha256 performance but I would assume that creating a key pair is more computing intensive than a sha256, if confirmed (I am not a crypto guy), then how relevant is this number ?



What is " receiver of the DET" ? (I understand of course but rather use correct wording)



" As such, use of DNSSEC and DNS-over-TLS by the DET registries is recommended" some justifications would be welcome as DNSSEC & DoT are vastly different beasts with different objectives.



" Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object" is it part of this specification? Else, please add something "out of scope"



This section would benefit from having a little more structure with more sub-sections (e.g., collision)



What about having a few paragraphs about revocation ?



# Sec 10.1

*** Should the title include ASTM ? Because, it seems that it is only about ASTM



# Sec 11.2

*** F3411 & drip-registries & CTA2063A & RFC 8032 should probably be normative.



App A

While interesting read, what is the link with DET ? Will DET comply with the EU rule?



App B

Humm DET could also be used by other industries, e.g., rail transportation or sea shipping.