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

[Robert Moskowitz <[e-mail]>]

I will go through IANA comments then push out -22 to the changes below:

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
>

hmm.. a chicken and egg problem.  I am looking into it.

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

I cannot find "USA Remote ID DET" anywhere in the draft.

Should all occurrences of "Hierarchical HIT" after the first be replaced 
with HHIT?

Per the Intro:

    HHITs as used within the context of Unmanned Aircraft System (UAS)
    are labeled as DRIP Entity Tags (DETs).  Throughout this document
    HHIT and DET will be used appropriately.  HHIT will be used when
    covering the technology, and DET for their context within UAS RID.

I think I have been consistent in following this.  But I am open to 
careful review and changes for closer adherence.

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

Done

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

hmm.  F3411-19 says: "Standard Specification for Remote ID and Tracking"

I wrote my text before req was far along, and have not looked back...

I will align with 9153.

And F3411-22 seems to have:

1 – Internet Engineering Task Force (IETF) Drone Remote Identification 
Protocol (DRIP) entity ID.

I will have to see if we can still r/Identification/ID/  or if we are 
too far into the publication process...

Don't know if I can fix this in all the places anymore...

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

Sigh.  We tend to get wrapped around the wagon wheel on Identity and 
Identifier.  Supposedly Identifier when talking about the what and 
Identity for the how.  I think.

> Please expand HIT and HIP at first use.
>

Think I got this.

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

See sec 1.1.

> # Sect 2.3:
>
> s/ HDA (Hierarchical HIT Domain Authority)/ HDA (HHIT Domain Authority)/ ?
>

done

> When defining HIP please add a reference to RFC.
>

Think I got it.

> # Sect 3
>
> In figure 1, some early explanations about "orchid hash" would be welcome.
>

Should I end the 1st sentence in Sec 3 with "] hash." ?

As here is where I say what ORCHID is.

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

the beginning of sec 3 references 7343.  7343 just says "context ID" and 
I was following that pattern.  Every usage of "context ID" pertains to 
ORCHIDs.  I could see this if there was some other "context ID" in this 
document?

> *** "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.
>

r/master/main/  it seems.

Can't maintain it myself.  Can't talk anyone into doing it.  Sigh, away 
it goes.  Did serve a purpose early on.

> # Sec 3.1
>
> Sometimes it is "HIP" and here it is "HIPv2", let's be consistent.
>

I feel that the places I use HIPv2 are appropriate as it refers 
specifically to HIPv2 items.  Now should all the HIP move to HIPv2? I 
think there is similarity to IKE and IKEv2.  But I will follow editorial 
guidance.

> # Sec 3.2.1
>
> Should the column heading be "HHIT Suite" rather than "HIT Suite" ?
>

oops.  done.

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

I went with "HDA Private Use" as I want to reflect this is HDA-bound.

> # 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"
>

I think that should be "RAAs should".  That an entity running an RAA, 
like the US Gov, would want to separate commercial from rec from mil.

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

This is a disagreement between authors and chairs.  I don't see the IANA 
having the expertise to handle this.  It will take some organization 
like ICAO or IATA or other aviation alphabet soup to determine the 
allocation.  Why add the IANA into the mix?  I was instructed to pull 
ICAO; I do not have official ICAO 'approval' that they will do this.  I 
will point out that they manage a LOT of number spaces for aviation; 
2063 Manufacture Code is only one.  And they do that for CTA/ASTM.

So that is why I have the basics here with pointers to registries to 
kick the can down the road.

> Which is " This DNS zone" ?
>

changed.

> Should "100" rather be "decimal 100" ?
>

Grumble.  changed here and sec 5.
>
> Should this be a "SHOULD" or even a "MUST" in "The PTR record could be 
> constructed" ?
>

It is an example.

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

Note added that IF this zone is used and it is for all HHITs, then IANA 
delegated.  This though makes the whole thing complex.


> # Sec 3.3.2
>
> It is useless to expand RVS as it has been done before.
>
> s/RVS servers/RVSs/ ?
>

Done

> # Sec 3.4
>
> Should "-Curve" be also in the section title ?
>

Yes.

> "HI" was already expanded before.
>

I do loose track in edits/adds on things like this.  thanks for catching it.

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

I now say 'update' in the intro, so thanks for catching this.  It is now 
also update.

> # 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".
>

The new ORCHID function is as follows:

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

Prefix (p)      : An IPv6 prefix of length p (max 28-bit-long).

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

added.

> # 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"
>

More of them?  Must have been copy and paste in the original writing.  
All changed.

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

I now say "update".  Do I need more?

> # Sec 4
>
> Should the section title be " Hierarchical HITs as DRIP Entity Tags" ?
>

Much simpler.

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

Organic nature of draft development.  It is gone now.

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

r/embedded/bound/

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

this is where DET is referenced outside of IETF.  Thus important.  I 
have simplified the text.

> # Sec 4.2
>
> *** Please provide a normative reference to base32.
>

What?  I learned this terminology back in 11th grade in 1966!  We used 
it in FORTRAN programming in CPS301 in 1968 at Michigan State U on our 
CDC6500 (for extra credit, my program converted any base to any base).  
There is a reference for this?  I never knew...

It was just part of the whole "what base does your computer use." 
thing.  We had fun with DECs with their 7-bit words.  CDC was 8-bit 
(Octal) but the math registers were 60-bit.  Did fun things with those.


> The discussion about not using base34 may be skipped IMHO.
>

I am willing to gut it (I was going to say 'cut' but I think the typo is 
more fun!).  Other opinions?

> *** " 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 ?
>

Grumble.  What was I thinking...

ICAO manages the CTA 2063 manufacture code registry.  Right now easy to 
get one via email.  Stu got one for his company's UA.  I imagine this as 
being an adjunct to the current ICAO process.  The company will provide 
the prefix|HID they want associated with their code. ICAO will add this 
to their registry.  This would be an addition to the current ICAO GRAIN 
DNS work I am part of.

This process may end up as part of drip-registries or just an ICAO 
process addition to the current CTA manf code registry.

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

Moved, but altered to fit in 3.3

4.5 may now need further work.

> # Sec 4.6
>
> *** What is " ASTM Authentication Message" (at least provide some 
> references).
>

I had, but Med had me pull:

    In practice, the Wrapper and Manifest authentication formats in the
    ASTM Authentication Message (Msg Type 0x2) [drip-authentication]
    implicitly provide this self-attestation.  A lookup service like DNS
    can provide the HI and registration proof (GEN-3 in [RFC9153]).

changed to

    In practice, the Wrapper and Manifest authentication formats
    (Sections 6.3.3 and 6.3.4 of [drip-authentication]) implicitly
    provide this self-attestation.  A lookup service like DNS can provide
    the HI and registration proof

Please offer a compromise?

> # 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" ?
>

Did.

> s/ following: Assume/ following: assume/
>

done

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

It is a problem.  But others have stated this is nothing compared to 
other loads.

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

This crept in ver -04.  I had to go back and see what I cut.  I can kind 
of remember why, as if you look at -03 I did not use this format.  So I 
will slap something in.  It is all examples...

> # Sec 6 and 7
>
> Unsure whether these 2 small sections belong to this document. Suggest 
> to remove them.
>

For 6, I will change might to will, as I know of work-in-progress.

For 7, Adam and I have debated how to point out what reqs met. 
Originally I did not have this section, but as he had this in auth, I 
mirrored it.  So we both need AD advise.  For myself, I don't see the 
need of this summary.  I have embedded, at each point, where reqs are met.

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

Done

> " through address randomization", which address ? MAC ?
>

Added MAC.

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

C2 defined in 9153 as Command and Control.

PHY is Physical Layer.  Standard usage when mentioning PHY/MAC tech like 
BT and WiFi.  I have never seen it expanded in IETF stuff, but can...

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

Well actually it applies to ALL of the RID types, but those are out of 
scope so changed to 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 ?
>

probably.  Let me see what IANA said and include this in their changes.

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

DRIP Entity Tags (DETs)

Is what is used elsewhere.

> # Sec 10
>
> *** Please provide a reference to "a Python script"
>

 From the authors?  We are not posting this script.

A script is was used to randomly generate 1M HHITs

???

> 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 ?
>

Numbers on keypair generation is a few times more than sha256 computes, 
so these people look at it as, "so it takes 3x more time total, big 
deal."  They look at it as we can do lots of sha256, we can do lots of 
keypair gens.

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

    This attack can be mitigated by the
    receiver of messages containing DETs using DNS to find the HI for the
    DET.

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

     As such, use of DNSSEC by the DET registries is
     recommended to provide trust in HI retrieval.

> " 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"
>

ref drip-auth.

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

I will think about a sub-section at:

"The two risks with hierarchical", but it is not forthcoming...

> What about having a few paragraphs about revocation ?
>

I will have to look back at what we told Valery on this.  Not for -22.  
I am running out of time before Passover.

> # Sec 10.1
>
> *** Should the title include ASTM ? Because, it seems that it is only 
> about ASTM
>

title changed.

> # Sec 11.2
>
> *** F3411 & drip-registries & CTA2063A & RFC 8032 should probably be 
> normative.
>

8032 yes, others no.  I think.

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

Open to moving this elsewhere, but want guidance.

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

YEP!