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

[Robert Moskowitz <[e-mail]>]

Eric,

Thank you for your comments.  I am starting on the next ver...

On 4/11/22 06:57, Eric Vyncke (evyncke) wrote:
>
> 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.
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit