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

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) 
the following questions, which are also in the XML file.

1) <!-- [rfced] For readability, we suggest the following update: 

Original:
   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses and thereby a trustable
   identifier for use as the Unmanned Aircraft System Remote
   Identification and tracking (UAS RID).

Perhaps:
   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses, which makes them trustable
   identifiers for use as an Unmanned Aircraft System Remote
   Identification (UAS RID) and tracking.
-->


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


3) <!-- [rfced] May we update this text as follows?  Otherwise, please 
clarify. 

Original:
   HHIT will be used when
   covering the technology, and DET for their context within UAS RID.

Perhaps:
   HHIT will be used when
   covering the technology, and DET will be used in the context of UAS RID.
-->


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


5) <!-- [rfced] The closing parentheis is missing.  Please confirm the 
placement of the closing parenthesis.  

Original:
   This contrasts with using general identifiers (e.g., a Universally
   Unique IDentifiers (UUID) [RFC4122] or device serial numbers as the
   subject in an X.509 [RFC5280] certificate.  In either case, there can
   be no unique proof of ownership/registration.

Current: 
   This contrasts with using general identifiers (e.g., a Universally
   Unique IDentifiers (UUID) [RFC4122]) or device serial numbers as the
   subject in an X.509 [RFC5280] certificate.  In either case, there can
   be no unique proof of ownership/registration.
-->


6) <!-- [rfced] For readability, we recommend the following update. 

Original:
   The document includes a set of algorithms with a guidance on the ones
   that are recommended to be supported by implementations.

Suggested:
   The document includes a set of algorithms and recommends the ones
   that should be supported by implementations.
-->


7) <!-- [rfced] The XML file includes author comments.  We have added 
[author] to these comments to clearly differentiate them from questions 
inserted by the RFC Production Center.  Please review and let us know if 
any updates are needed; otherwise, these will be deleted. 
-->


8) <!-- [rfced] Does this text mean the protocol upon which HI, HIT and 
HHIT are based?  If this is correct, perhpas the reference should appear 
after "Host Identity Protocol (HIP)"? 

Original:
   HIP (Host Identity Protocol)
      The origin [RFC7401] of HI, HIT, and HHIT.

Perhaps:
  Host Identity Protocol (HIP) [RFC7401]: 
     The origin of HI, HIT, and HHIT.
-->


9) <!-- [rfced] Please review instances of <artwork> in the XML and let us 
know if any should instead be <sourcecode>.  If <sourcecode, please 
consider wheter the "type" attribute should be set (see https://www.rfc-editor.org/materials/sourcecode-types.txt).  
If the list does not contain an applicable type, then feel free to let us
know. Also, it is acceptable to leave the "type" attribute not
set.  
-->


10) <!-- [rfced] For clarity, we suggest not using "4/8-bit". Does this 
mean, "4 and 8 bit"?  May we update this text as follows?

Original:
   These are a
   superset of the 4/8-bit HIT Suite ID as defined in Section 5.2.10 of
   [RFC7401].

Perhaps:
   These are a
   superset of the 4-bit and 8-bit HIT Suite IDs as defined in Section 
   5.2.10 of [RFC7401].
-->


11) <!-- [rfced] For readability, please consider whether this update 
correctly conveys the intended meaning.

Original: 
   The rationale for the 14/14 HID split is described in Appendix B. 

Perhaps:
   The rationale for splitting the HID into two 14-bit domains is 
   described in Appendix B.
-->


12) <!-- [rfced] Will "zone tree" be clear for the reader?  In addition, 
is "in the actual zone tree" correct (as opposed to, for example, 
"regarding the actual zone tree" )? 

Original:
   Thus
   further thought will be needed in the actual zone tree and
   registration process [drip-registries].
-->


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


14) <!-- [rfced] Is NIST SP 800-185 the reference for cSHAKE?  May we 
update text as follows?

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

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


15) <!-- [rfced] We have updated [TBC_DRIP_REGISTRY] to point to the 
"Hierarchical HIT (HHIT) Suite ID" registry <https://www.iana.org/assignments/drip> and added an informative reference.  Please review and 
let us know if any updates are needed. 

Original:
                     ...  When used for HHIT generation this is
                     the HHIT Suite ID [TBC_DRIP_REGISTRY].

           Note to the RFC Editor: Please replace [TBC_DRIP_REGISTRY]
               with the pointer to the IANA registry created in
               Section 8.2.

-->


16) <!-- [rfced] In section 3.5.1, is this formatting update correct?  
Is this line intended to appear as part of the definition list?  We have 
currently formatted it as a separate item (i.e., not part of the list).  
Please review. 

Original:
   Sizeof(p + n + o + m) 128 bits
-->


17) <!-- [rfced] It is not clear to us what "call for this update" means.  
Please review.  follows?  

Original:
   The cSHAKE function call for this update is:

Perhaps:
   The update for this cSHAKE function is as follows:
-->


18) <!-- [rfced] Please confirm that 'UAS ID type 4, "Specific Session ID 
(SSI)"' is not an IANA-registered value.  In addition, we are unable to 
verify SSI 1 and SSI 2.  We do not see  related actions in the IANA 
Considerations section, and we are unable to access [F3411-22a] 
(https://www.astm.org/f3411-22a.html)?  Please review and let us know if 
any updates are needed. 

Original: 
   The ASTM Standard Specification for Remote ID and Tracking
   [F3411-22a] adds support for DETs.  This is only available via the
   new UAS ID type 4, "Specific Session ID (SSI)".

   ... 

   SSI 1  IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID.

   SSI 2  3GPP - IEEE 1609.2-2016 HashedID8
-->


19) <!-- [rfced] Note that we updated the link for Section 5 to go 
directly to this line of <artwork>.  Please let us know if any corrections 
are needed. 

Section 5: 
   2001:30:280:1405:a3ad:1952:ad0:a69e

Section 4.2: 
Original: 
   Using the sample DET from Section 5 that is for HDA=20 under RAA=10
   and having the ICAO CTA MFR Code of 8653, the 20-character CTA 2063-A
   Serial Number would be:

       8653F02T7B8RA85D19LX
-->


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


21) <!-- [rfced] Please review the questions below regarding this text:

Original:
   There are two approaches for storing and retrieving DETs using DNS.
   The following are examples of how this may be done.  This will serve
   as guidance to the actual deployment of DETs in DNS.  However, this
   document does not provide a recommendation.  Further DNS-related
   considerations are covered in [drip-registries].

   *  As FQDNs, for example, "20010030.hhit.arpa.".

   *  Reverse DNS lookups as IPv6 addresses per [RFC8005].

a) Please confirm that these are examples, and not the two approaches.  

b) For clarity, may we update the text to read:

   However, this document does not provide a recommendation about which 
   approach to use.  
-->


22) <!-- [rfced] Is the HDA providing HHIT with a detailed response or 
should this read "the detailed HHIT response"?  Please review. 

Original:
   The HDA SHOULD provide DNS service for its zone and provide the HHIT
   detail response.
-->


23) <!-- [rfced] Does "could be to" mean "result in"?  Are the two periods 
intentional? 

   A DET reverse lookup could be to:

       a69e.0ad0.1952.a3ad.1405.0280.20.10.20010030.hhit.arpa..
-->


24) <!-- [rfced] Section 8.1: Please note that we updated the registration 
entry to match what appears in the IANA registry.  Please let us know if 
any updates are needed. 
-->


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


26) <!-- [rfced] Section 8.2: Should the title for "Hierarchical HIT (HHIT) 
Suite ID" be plural (i.e., "Hierarchical a HIT (HHIT) Suite IDs")? 
-->


27) <!-- [rfced] Section 8.2: <https://www.iana.org/assignments/drip> lists 
this document as the refernece for value 0 (Reserved).  We have updated the 
table to match.  We note that the "HIT Suite ID" references RFC 7401 for 
value 0 (Reserved), but this seems ok since it is outside of the 1-31 
range.  

In addition, please note that the "HIT Suite ID" registry seems to have 
values 1-15, but the text below indicates values 1-31 should match "HIT 
Suite IDs" registrations.  

Please review and let usk now if any updates are needed. 

Original:
        HHIT Suite          Value    Reference
        RESERVED            0

   ...

      The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be
      replicated as HIT Suite IDs (Section 8.4) as is TBD3 here.

Note that similar text appaers in Section 8.4: 

Original: 
      The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F
      MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here.

-->	


28) <!-- [rfced] Should this document be listed as a reference for the full 
"CGA Extension Type Tags" registry, or just the entry for "0x00B5 A69C 795D 
F5D5 F008 7F56 843F 2C40"?  If both, perhaps:

Original:
   This document requests that this document be added to the reference
   field for the "CGA Extension Type Tags" registry [IANA-CGA], where
   IANA registers the following Context ID:

Perhaps:
   This document has been added as a reference for the 
   "CGA Extension Type Tags" registry [IANA-CGA].  IANA has registered the 
   following Context ID in this registry:
-->


29) <!-- [rfced] Section 8.3: We converted the registration text into a 
table for clarity and to better align with what appears in the IANA 
registry..  Please let us know this causes any concern. 

Original:
      Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40  [This]

Current:
         +===========================================+===========+
         | CGA Type Tag                              | Reference |
         +===========================================+===========+
         | 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 | RFC 9374  |
-->


30) <!-- [rfced] We are having trouble parsing "studies of hash size to 
cryptographic hash attacks".  Does this mean "studies of hash size in 
relation to cryptographic hash attacks"? 

Original: 
   There are no known (to the
   authors) studies of hash size to cryptographic hash attacks.
-->


31) <!-- [rfced] What is being signed - the object or the HHIT?

Original:
   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 detailed in [drip-authentication].

Perhaps: 
   Another mitigation of HHIT hijacking is when the HI owner (UA) supplies
   an object containing the HHIT that is signed by the HI private key of 
   the HDA as detailed in [drip-authentication].
-->


32) <!-- [rfced] For readability, please consider whether the suggested 
text correctly conveys the intended meaning.

Original:
   Collision                                
   resistance (more important that it implied second-preimage
   resistance) makes it statistically challenging to attacks.

Perhaps:
   Collision                                
   resistance (and more importantly, the implied second-preimage
   resistance) makes attacks statistically challenging. 
-->


33) <!-- [rfced] To avoid awkward hyphenation and for clarity, may we 
update this sentence as follows? 

Original:
   HHITs contain the ID for the cryptographic suite used in its
   creation, a future post quantum computing safe algorithm that fits
   the Remote ID constraints may readily be added.

Suggested:
   HHITs contain the ID for the cryptographic suite used in its
   creation, a future algorithm that is safe for post-quantum computing
   that fits the Remote ID constraints may readily be added.
-->


34) <!-- [rfced] May we update this sentence for readability? 

Original: 
   The best that
   might be done within this Basic ID Message is 4 bytes truncated from
   a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is
   16).

Suggested: 
   Truncating 4 bytes from a HI signing of the HHIT (the UA ID field is 
   20 bytes and a HHIT is 16) within this Basic ID Message is the best 
   that can be done. 
-->


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


36) <!-- [rfced] Please confirm that MAC refers to Media Access Control. 
For example:   

   Further, the MAC address of the wireless interface used for Remote ID
   broadcasts are a target for UA operation aggregation that may not be
   mitigated through MAC address randomization.
-->


37) <!-- [rfced] Is "historically tracking" correct? We wonder if "tracking 
the history of the UA's activity" is meant?  

Original:
   Finally, it is not adequate to simply change the DET and MAC for a UA
   per operation to defeat historically tracking a UA's activity.
-->


38) <!-- [rfced] Please consider whether the suggested update improves 
readability and maintains the intended meaning.

Original:
   UA/GCS binding is complicated with changing MAC addresses;
   historically UAS design assumed these to be "forever" and made setup
   a one-time process.

Perhaps:
   UA/GCS binding is complicated because of the changing MAC addresses;
   historically, UAS design assumed the ddresses to be static "forever" 
   and made setup a one-time process.
-->


39) <!-- [rfced] Does "changing the DET" trigger other changes, or it is the beginning of a set of changes?  

Original:
   Simply changing the DET
   only starts the changes that need to be implemented.

Perhaps: 
   Changing the DET is only the start of
   the changes that need to be implemented.
-->


40) <!-- [rfced] Does "(or similar behaving)" mean "(or a similar 
purpose)"?  And, please consider whether "will take years of deployment 
experience" should be "deployment experience will take years".

Original:
   Perhaps a single RAA providing HDAs for delivery service (or similar
   behaving) UAS could 'get by' with a 2048 HDA space (11-bits).  ... 
   But as this is speculation, and it will take years
   of deployment experience, a 14-bit HDA space has been selected.

Perhaps:
   Perhaps a single RAA providing HDAs for delivery service (or a similar
   purpose) UAS could 'get by' with a 2048 HDA space (11-bits).  ... 
   However, as this is speculation and deployment experience will take 
   years, a 14-bit HDA space has been selected.
-->


41) <!-- [rfced] We are having trouble parsing this sentence.  Please consider whether the suggested update conveys the intended meaning.  Otherwise, please clarify. 

Original:
   The HDA space is large enough that some to use part for
   government needs as stated above and for small commercial needs.  Or
   the State may use a separate, consecutive RAA for commercial users.

Perhaps:
   The HDA space is large enough that a portion may be used for
   government needs as stated above and small commercial needs.  
   Alternatively, the State may use a separate, consecutive RAA for 
   commercial users.
-->


42) <!-- [rfced] Will "nibbled fields" be commonly understood by readers? 

Original:
   The DET upper 64 bits appear to be oddly constructed from nibbled
   fields, when typically seen in 8-bit representations.
-->


43) <!-- [rfced] Does "leaving remaining RAA and HDA combined to" mean 
"which leaves the remaining RAA and HDA to combine to"?

Original:
   The left most 4 bits of the RAA, all zeros, combine with the prefix
   to form 2001:0030:, leaving remaining RAA and HDA combined to:
-->


44) <!-- [rfced] Does "does not lend to using" mean "is not well suited for 
using"?  

Original:
   The alphabet used in CTA 2063-A Serial Number does not lend to using
   any published Base32 encoding scheme.
-->


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


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


Thank you.

RFC Editor


On Feb 26, 2023, at 3:43 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/02/26

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9374.xml
   https://www.rfc-editor.org/authors/rfc9374.html
   https://www.rfc-editor.org/authors/rfc9374.pdf
   https://www.rfc-editor.org/authors/rfc9374.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9374-diff.html
   https://www.rfc-editor.org/authors/rfc9374-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9374-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9374.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9374.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9374

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9374 (draft-ietf-drip-rid-37)

Title            : DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
Author(s)        : R. Moskowitz, S. Card, A. Wiethuechter, A. Gurtov
WG Chair(s)      : Daniel Migault, Mohamed Boucadair
Area Director(s) : Erik Kline, Éric Vyncke