Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review

[Sandy Ginoza <[e-mail]>]

Greetings all,  

We believe we have updated the document as requested, but please review closely.  In addition, we have some followup questions below.  Please note that comments have been condensed into the mail below; our comments are preceded by [rfced]. 

The current files are available here: 

   https://www.rfc-editor.org/authors/rfc9374.txt
   https://www.rfc-editor.org/authors/rfc9374.pdf
   https://www.rfc-editor.org/authors/rfc9374.html
   https://www.rfc-editor.org/authors/rfc9374.xml

AUTH48 diff:
   https://www.rfc-editor.org/authors/rfc9374-auth48diff.html

Comprehensive diffs: 
   https://www.rfc-editor.org/authors/rfc9374-diff.html
   https://www.rfc-editor.org/authors/rfc9374-rfcdiff.html


> On Feb 27, 2023, at 5:33 PM, Robert Moskowitz <[e-mail]> wrote:

[note that resolved issues have been snipped]


>> 2) <!-- [rfced] Does "This" refer to this document or RFC 9153 (i.e., is
>> RFC 9153 the foundational document)?
>> 
>> Original:
>>    Drone Remote ID Protocol (DRIP) Requirements [RFC9153] describe an
>>    Unmanned Aircraft System Remote ID (UAS ID) as unique (ID-4), non-
>>    spoofable (ID-5), and identify a registry where the ID is listed (ID-
>>    2); all within a 19-character identifier (ID-1).
>> 
>>    This DRIP foundational document (i.e., all else in DRIP enables or
>>    uses it) describes (per Section 3 of [drip-architecture]) the use of
>>    Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting
>>    IPv6 addresses and thereby a trustable identifier for use as the UAS
>>    Remote ID.
>> -->
> 
> Yes, this document.  Not 9153.
> 
> I am not finding any changes to lessen the confusion.  Perhaps:
> 
> This document, foundational to DRIP as all other documents will enable or
>    uses it, describes (per Section 3 of [drip-architecture]) the use of
> 
> I don't know if this helps.

[rfced] Perhaps:
   This RFC is a foundational document of DRIP, as it describes  the use of
   Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting
   IPv6 addresses and thereby a trustable identifier for use as the UAS
   Remote ID (see Section 3 of [DRIP-ARCH].  All other DRIP-related
   technologies will enable or use HHITs as multipurpose remote identifiers.




>> 4) <!-- [rfced] May we replace instances of "Hierarchical HITs" with
>> "HHITs" throughout once the abbreviated form has been introduced?
>> For example:
>> 
>>    Hierarchical HITs provide ...
>> 
>>    Hierarchical HITs are valid, ...
>> 
>> 
>>    Hierarchy ID (HID) ...
>> -->
> 
> Yes please, sloppy of me not to consistently just use HHIT (and HID).

[rfced] For the most part, we have removed expansions once they have been introduced (they are expanded in both the abstract and introduction).  We have left some other expansions in select places, for example:

HIDs are further divided into two fields:
- 14-bit Registered Assigning Authority (RAA)
- 14-bit HHIT Domain Authority (HDA)



>> 13) <!-- [rfced] May we update this to specify that the EdDSA HI uses the
>> value assigned per [ipseckey-eddsa] for IPSECKEY RR encoding?
>> 
>> Original:
>>    The new EdDSA HI uses [ipseckey-eddsa] for the IPSECKEY RR encoding.
>> 
>> Suggested:
>>    The new EdDSA HI uses value assigned per [ipseckey-eddsa] for IPSECKEY
>>    RR encoding.
>> -->
> 
> It is more than the value.  It is also how the public key is encoded.  Perhaps
> 
> The 'Algorithm Type' value and EdDSA HI encoding are assigned per [ipseckey-eddsa].

[rfced] Updated as noted here.  Please confirm that "IPSECKEY RR encoding” is not needed. 




>> 20) <!-- [rfced] We are having trouble parsing "88-byte self-proof
>> evidence".  If possible, please clarify.
>> 
>> Original:
>>    The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an
>>    88-byte self-proof evidence (timestamp, HHIT, and signature of these)
>>    to provide proof to Observers of Remote ID ownership (GEN-1 in
>>    [RFC9153]).
>> -->
> 
> The term "evidence" (and "endorsement") are defined in drip-arch and are from RATS rfc 9334.  Sec 2.3 says to look in drip-arch for terms.  We had quite a debate on the list about where terms are defined in our documents.
> 
> Perhaps first time "evidence" and "endorsement" are used point to rfc9334?
> 
> These terms/concepts are really important in DRIP and heavily used in drip-auth.


[rfced] We have not made any changes, but we wonder if “self-proving evidence” is meant? 



>> 25) <!-- [rfced] Section 8.2 seems to create the "Drone Remote ID Protocol"
>> group of registries, which contains the "Hierarchical HIT (HHIT) Prefixes"
>> and "Hierarchical HIT (HHIT) Suite ID" registries.  Is it correct that the text about expert review only applies to "Hierarchical HIT (HHIT)
>> Prefixes", as the registration procedure for "Hierarchical HIT (HHIT) Suite
>> ID" is IETF Review?
>> 
>> If this is correct, may we move the text describing criteria for the
>> designated expert to appear after the table 8, to make it more clear that
>> it applies to the "Hierarchical HIT (HHIT) Prefixes" registry?  Would it be
>> helpful to divide 8.2 into the following sections:
>> 
>> 8.2.1.  Hierarchical HIT (HHIT) Prefixes
>> 8.2.2.  Hierarchical HIT (HHIT) Suite IDs
>> 
>> Note that we have removed this sentence entirely, as we believe it is
>> common practice for IANA to have at least two experts for a given registry.
>> Please let us know if you prefer otherwise.
>> 
>> Original:
>>         It is suggested that multiple
>> 	designated experts be appointed for registry change requests.
>> -->
> 
> Yes, expert review applies to the prefixes only.  Lots of discussions about that.  And SuiteIDs will follow standard IETF review.  Thus the change you recommend for 8.2.1 and 8.2.2 is is good.  And can drop "two experts" sentence.  That text was a copy/paste.

[rfced] We have added subsections 8.2.1 and 8.2.2.  Please review to ensure the updates are correct. 



>> 35) <!-- [rfced] We are having trouble parsing this sentence.  Does "the
>> observer can see the UA or that information is validated" mean that the
>> "observer can see that the UA or the information in question is validated"?
>> Please clarify.
>> 
>> Original:
>>    Proof of UA transmission comes when the Authentication Message
>>    includes proofs for the ASTM Location/Vector Message (Msg Type 0x1)
>>    and the observer can see the UA or that information is validated by
>>    ground multilateration.
>> -->
> 
> A UA broadcasts its location.  And the observer can even authenticate the message came from a UA with a specific DET.  Is it really at that location?  What is the proof?
> 
> The observer "sees" a UA at that location.
> ground multilateration of the broadcast messages compute the same location as the validated location broadcast.
> 
> Now how do you say this without a paragraph or two?  Well there is the prior para to set the stage.
> 
> Proof of a specific UA as the source of a transmission comes when...


<atw>
In conference with Stu, multilateration is neither required nor always feasible. Whatever text we
settle upon must make clear that we are not specifying a particular method of validation. We are
stating that signed novel information must be somehow validated to provide trust that the sender
actually possesses the private key corresponding to the HHIT. This could be a simple sanity check
that the UA visually sighted by the observer appears to be in approximately the location reported
in a signed Location/Vector Message.
</atw>


Bob: 
IMO the text only presents multilateration as one method of proof.  It is not a requirement.

Visual sighting is included as well.

It is the whole point that this is a broadcast media.  So you can trust the messages coming from something, but can you trust the content?

My position is leave the text as is.



[rfced] Perhaps:
   Proof of UA transmission comes, for example, when the Authentication Message
   includes proof of the ASTM Location/Vector Message (Msg Type 0x1)
   and a) the observer can see the UA or b) the location information is validated by
   ground multilateration.




>> 45) <!-- [rfced] Would you like to make use of <sup> for superscript
>> in this document? You can see how it looks here:
>> 
>> https://www.rfc-editor.org/authors/rfc9374-sup.html
>> https://www.rfc-editor.org/authors/rfc9374-sup.pdf
>> https://www.rfc-editor.org/authors/rfc9374-sup.txt
>> 
>> Note: In the HTML and PDF, it appears as superscript.
>> In the text output, <sup> generates a^b.
>> -->
> 
> I did not even consider what would work here for .txt and .pdf and .html.
> 
> So please do what works best!  Maybe I will learn something for future use!


[rfced] We have updated the document to use superscript.  Please review.  In particular, please review this instance in the text and html output (at minimum) to ensure the groupings are correct:

Original:
       p = 1 - e^{-k^2/(2n)}

TXT:
       p = 1 - e^({-k^2/(2n)})

HTML:
   https://www.rfc-editor.org/authors/rfc9374.html#appendix-D





>> 46) <!-- [rfced] Please review the following regarding terminology:
>> 
>> a) Throughout the text, the following term appears to be used
>> inconsistently. Please review these occurrences and let us know if/how they
>> may be made consistent.
>> 
>> authentication message vs Authentication Message
>> 
>> b) Note that instances of "IPV6" have been updated to "IPv6" (lowercase v).
>> 
>> c) In addition, note that we have used the following articles.  Please let us know if any corrections are needed.
>> 
>> an HI (read "hy")
>> an HDA (read as letters, i.e., an eche dee aye)
>> a HIP (read as the word hip)
>> a HIT (read as the word hit)
>> a HHIT - how is this read?
>> -->
> 
> We were very careful where we capitalized authentication message vs Authentication Message
> 
> Are we talking about the actual ASTM Authentication Message (msg type 0x2) or speaking about an authentication message.  So please the case alone.  Lots of reviews on this usage.
> 
> b)  thank you.
> 
> HI should probably be "a HI" as you allude?
> HDA, HIP, and HIT are right above.
> 
> HHIT is read by letter or "H HIT".  So that seems it should be an HHIT.

<atw>
in conference with Stu, user may not understand this subtle distinction! Perhaps text is needed the terminology section to enlighten that capitalization means F3411 specifically and uncapitalized is generic.
<atw>


[rfced] We have not made any changes - please let me know if any corrections are needed. 



From Med:
* Section 3.5: revert to the old wording

OLD: 
  *  the use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185] for the
     hashing function.

NEW:
  *  the use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the
     hashing function.


[rfced] The text currently reads as follows:

  *  the use of cSHAKE [NIST.SP.800-185] for the hashing function.




- From Bob: ALL the definitions were IMPROPERLY altered.

[rfced] Apologies - we have revered the order of the expansions and abbreviations. 


- From Bob:

One further thought.  Where the term comes from NIST, I have that in the parenthetical expansion of the term.  But I don't do that for when the term is from another RFC.  Should the RFC reference be moved up as in:

   HI (Host Identity [RFC9063]):
      The public key portion of an asymmetric key pair.

   HIT (Host Identity Tag [RFC7401]):
      A 128-bit handle on the HI.  HITs are valid
      IPv6 addresses.

   RVS (Rendezvous Server [RFC8004]):
      A Rendezvous Server such as the HIP Rendezvous Server for enabling
      mobility.

Note that this only applies to those terms that have the text "as defined in" (and HIT should have it).

[rfced] We have not moved the citation tags, as the current format is more typical in RFCs.  Please let us know if you prefer otherwise.  
Also, the definitions are preceded by the following:
   This document uses the terms defined in Section 2.2 of [RFC9153] and
   in Section 2 of [DRIP-ARCH].  The following new terms are used in the
   document:

Perhaps we should change the last sentence as follows to remove “new”, as many of these terms are not new: 
   In addition, the following terms are used in this document. 



- [rfced] New questions regarding Section 4.5: DRIP Entity Tag (DET) Registry

a) Apologies if I am missing something obvious here, but to what registry does this refer?  This document uses "DET Registry” and Section 4.5 is entitled "DRIP Entity Tag (DET) Registry”.  Section 4.5 references draft-ietf-drip-registries.  I expected draft-ietf-drip-registries to create a DET registry, but it refers back to this document, which creates the "Drone Remote ID Protocol” Registry.  Is it correct that DET Registry refers to the DRIP Registry <https://www.iana.org/assignments/drip/drip.xhtml>?   Can this text be clarified? 

b) Is [DRIP-REG] being referred to here because it defines the registration process?  If so, where are these procedures defined?  

Original: 
A registration process, [DRIP-REG], ensures DET global uniqueness (ID-4 in Section 4.2.1 of [RFC9153]).

c) In the sentence above: if [DRIP-REG] defines the registration process, may we update the text as follows?

Perhaps: 
The registration process defined in [DRIP-REG] ensures DET global uniqueness (ID-4 in Section 4.2.1 of [RFC9153]).


Thank you!
RFC Editor/sg






> 
> 
>> Thank you.
>> 
>> RFC Editor
> 
> And thank you!
> 
> I assume we will be going another round with these edits.
> 
> Bob
> 
>