DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
draft-ietf-drip-rid-37

# Internet AD comments for {draft-ietf-drip-rid-28}
CC @ekline

## Comments

### S3.5.1

* "Care must be considering the size" doesn't quite read correctly to me.
  "Consideration must be given to the size of the hash portion..."?

* This whole final paragraph I find a bit obscure.  Especially since
  mentally I'm comparing it to layout depicted in Figure 1. Is "(n)" where
  the RAA and HDA bits get encoded?  I assume that's what's meant by the
  reference to "28 bits" at the end.

  I think just being a bit more explicit should suffice to make it that
  much easier to follow.

## Nits

### S9

* "you'd be happy" -> "an attacker may well be satisfied"

  Consider changing all 2nd person usages to 3rd person.

Thanks for addressing my discuss point and comments. I've pasted the previous discuss point below, for posterity.

Previous discuss:

1. In §3.2,

   The following HHIT Suite IDs are defined:

        HHIT Suite          Value
        RESERVED            0
        RSA,DSA/SHA-256     1    [RFC7401]
        ECDSA/SHA-384       2    [RFC7401]
        ECDSA_LOW/SHA-1     3    [RFC7401]
        EdDSA/cSHAKE128     TBD3 (suggested value 5)   (RECOMMENDED)

What, exactly, does the notation "RECOMMENDED" on the last quoted line mean? AFAICT there's no unambiguous way to parse this. My guess is that it's meant to mean "this is the suite we think you should use". Whatever the intended meaning, please elaborate to make the meaning clear. I suggest removing the notation from the table, and providing prose in some appropriate section instead, with "RECOMMENDED" if you think the RFC 2119 keyword is needed. If desired, you could xref that section from the table, although I don't think that's really necessary.

This comment also applies to the similar lines in §3.4.1, §3.4.1.1, and §3.4.2. The use in §3.4.1.1 is especially confounding, since the prose right before the table tells us that (all of) "the following EdDSA curves are required" (but evidently not REQUIRED)... but only some of the required curves are RECOMMENDED? I definitely have no clue, then, what "RECOMMENDED" means in this section. RFC 2119 basically defines RECOMMENDED as a weaker form of REQUIRED, but that doesn't seem to be how you're using it.

Similarly, I have no clue what "RECOMMENDED" is meant to mean in its several uses in §8.2 and §8.4. I suggest simply removing it from those sections entirely.

(Taken together, this comment covers every use of RECCOMMENDED in the document.)

Comments:

2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

   Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
   2063-A format is defined as follows:

   Serial Number   :=  MFR Code | Length Code | MFR SN

The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that:

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  
   
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1, 

                                                     Care
   must be considering the size of the hash portion
   
Something's missing here. Perhaps "Care must be taken in considering..."?

11. In §4.2,

                                                   Definition of this
   mapping service is currently out of scope of this document.
   
I think you can drop "currently" considering you're going to press as an RFC.

Thanks for resolving my IANA Considerations concerns.

Rather than repeating them, I support Paul's and John's DISCUSS positions.

I like that we're recycling existing IETF technologies to map to a new purpose like this.  However, like Warren (who did not DISCUSS it or I would support that too), I'd like to hear about what consultation was done with DNSOP, if any.  I have the same question about REGEXT for the EPP references.

Section 3.3.1 says:

   [...]  An RAA MUST
   provide a set of services to allocate HDAs to organizations.  

Are we talking about online services of some kind?  If so, which ones?  If not, is this an appropriate use of BCP 14?

Sections 8.3 and 8.5 should be explicit that the Reference for the new entry is this document.  Even though that's obvious, the instructions should be complete.  (Note, for example, that they're correctly different in Section 8.4.)

OLD DISCUSSES:

#1

   Note that if the zone hhit.arpa is ultimately used, some registrar
   will need to manage this for all HHIT applications.

Regardless of what zone is used, someone needs to keep it operational.
It might be an attractive target to attack, eg to try and avoid drones
being shut down. I would feel much better if this zone was optional,
not mandatory. (but if optional, one could also argue maybe not have it
at all?)

   If the HHITs cannot be
   looked up with services provided by the registrar identified via the
   embedded hierarchical information or its registration validated by
   registration attestations messages [drip-authentication], then the
   HHIT is either fraudulent or revoked/expired.

That's quite catastrophic if there is a Registrar/Registry outage. Would
all the drones get shot down or would they all be ignored (so they can
fly to their terrorism target)

#2

As DISCUSS'ED by others, https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm does not seem to have a third field for "status" to
denotate RECOMMENDED, REQUIRED, etc, even though RFC 7401 creates the registry,
uses the terms too but doesn't populate a status field. Perhaps this or another
short RFC could do so.

Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry
calls it "Algorithm Profile" (singular) and "Value" (singular)

#3

Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the
slash and pipe symbols on those first and second lines got swapped by
accident?

#4

   The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding:

      Value  Description

      TBD2 (suggested value 4)
             An EdDSA key is present, in the format defined in [RFC8080]

I have asked the Expert of this Registry whether they are okay with this
entry to the ipseckey-rr-parameters registry. It might be confusing for IKE.

COMMENTS:


#1

   100.hhit.arpa   IN PTR      raa.example.com.

Please add a trailing dot, eg "100.hhit.arpa."

Similarly for:

    100.50.det.uas.icao.int   IN PTR      foo.uss.icao.int.

#2

      HIP DNS RR (Resource Record)

Add reference to RFC5205 on its first mention.

#3

    However, this document does not intend to provide a recommendation.

weasel wording. It should probaby just state "this document does not provide
a recommendation."


#4

   The individual DETs may be potentially too numerous (e.g., 60 - 600M)
   and dynamic (e.g., new DETs every minute for some HDAs) to store in a
   signed, DNS zone.

This can be achieved with online signing. I would remove this speculative
sentence unless it is backed by some real numbers.

(Updated ballot)

Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions.

Thank for the revised text from -29 to -32.  It addressed all of my DISCUSS and some of my COMMENT points.  Further details with history below.

These were DISCUSSes.  From https://mailarchive.ietf.org/arch/msg/tm-rid/Of4ZUih3oiHvwZDrYG9cjBf27-Q/

>>> I’m having trouble following along on where the guidance for offline
>>> verification is described – who exactly signs what with what key and 
>>> in what
>>> format is this stored.  Is this considered in-scope for this 
>>> document?  Given
>>> the asserted security properties,
>>
>> This guidance that lines up with 9.2 that the DET alone is not 
>> enough, go read drip-auth.  But this is the core that makes drip-auth 
>> even possible.
>>
>>> -- I’ll note that draft-ietf-drip-auth is an informative reference.
>>
>> Yes.  drip-rid does not, itself, need drip-auth.  A trustworthy 
>> implementation would use drip-auth to provide full message trust, 
>> including of the messages providing the DET.
>
> Please see the recent addition to drip-auth, sec 1.1
>>
>>> -- What exactly needs to be in the offline Observer’s cache?  I 
>>> couldn’t find
>>> that in draft-ietf-drip-auth.
>>
>> Well, then I need more updates to drip-auth!  The cache, minimally is 
>> the HDA's DET and HI.  48 bytes worth per entry. As it says above:
>>
>>    Only a small cache that contains the
>>    HDA's HI/HHIT and HDA meta-data is needed by the Observer.
>>
>> So the offline attestation in defined in drip-auth has the HDA's HHIT 
>> (DET).  Use this to retrieve the HDA's HI.  Use this HI to validate 
>> the signing of the registration attestation within the larger 
>> attestation.  This does need to be clearly defined in drip-auth.  I 
>> am making a note to check this out.
>
> This has recently been updated in drip-auth, sec 1.1

Adding the appropriate sub-section drip-auth reference would be helpful.  It’s in a few places further into the document (not Section 1.1)


These were DISCUSSes and https://mailarchive.ietf.org/arch/msg/tm-rid/aq-wsciitaB4h-CghTpPwDn1KuM/

>> ** Section 9.
>>     Therefore, the HHIT registration and HHIT/HI registration validation
>>     is strongly recommended.
>>
>> If validation isn’t done, who are the promised security guarantees of 
>> global
>> non-collision possible?  Practically, why isn’t this a MUST?
>
> I am open to it being a MUST, but I think I was advised to back off to 
> a strongly recommended.
>
> If not registered, no offline attestation available, only the 
> self-attestation.

Understood.  Thanks for explaining.  I recommend added this explanation into the text to justify why the MUST isn’t needed.

>> ** Section 9.5.
>>
>>     The UAS/USS registration
>>     process should include registering the DET and MUST reject a
>>     collision, forcing the UAS to generate a new HI and thus HHIT and
>>     reapplying to the DET registration process.
>>
>> How does a UAS “generate a new HI” in the case of a CTA2063A or 
>> manufacturer
>> hard-coding the HHIT per Section 3.2 of draft-ietf-drip-arch-24?
>
> See drip-registries.  That is covered there, and it parallels ANIMA in 
> many ways.  The CTA encoded HHIT is a permanent DET to bootstrap 
> registration of one or lots of operational (Session) DETs.

Strongly recommend putting into reference to relevant section in drip-registries.

From https://mailarchive.ietf.org/arch/msg/tm-rid/DGQ5pQ-TNkzG-WDoHoOnTVoA-so/:


> > ** Section 4.
> >     The original UAS ID Types 1 - 3 allow for an UAS ID with a maximum
> >     length of 20 bytes, this new SSI (Type 4) uses the first byte of the
> >     ID for the SSI Type, thus restricting the UAS ID of this type to a
> >     maximum of 19 bytes.  The SSI Types initially assigned are :
> >
> >     ID 1  IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID.
> >
> >     ID 2  3GPP - IEEE 1609.2-2016 HashedID8
> >
> > -- Is this text saying that the HHITs format defined in this text can be used
> with a UAS ID Type = 1, 2, 3?

>No, at one time I had the full UAS ID Type table here and I was asked to 
> cut it:
>
>    ASTM Standard Specification for Remote ID and Tracking [F3411-19]
>    specifies three UAS ID types:
>
>    TYPE-1  A static, manufacturer assigned, hardware serial number per
>            ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers"
>            [CTA2063A].
>
>    TYPE-2  A CAA assigned (presumably static) ID.
>
>    TYPE-3  A UTM system assigned UUID [RFC4122].  These can be dynamic,
 >           but do not need to be.
>
> Only the new Type-4, Session ID can support HHITs.  Well your type-1 CTA 
> SN COULD be an encoded HHIT.

> Do you feel that this information should be added or text saying that 
> HHIT is only used in type-4?

I would probably err on the side of saying less and make clear that only type-4 is relevant to HHIT.


> ** Section 4.2.  Please provide a normative reference for Base32.  RFC4648?
> We have had this discussion.  The CTA alphabet selection precludes 
> referencing ANYthing I have found out there.  We MUST work with the 
> letters and numbers they allow and it DOES NOT map to 4648.  We had this 
> discussion during early reviews.

I leave this to WG and the AD.  We should technically have a citation on how to compute this Base32 variant if it isn’t the expected on RFC4648.

I'm clearing my DISCUSS because my points were addressed, but I am still concerned by the issue in Comment 2 -- just because you *can* put stuff in the DNS, doesn't mean that you *should*. The DNS is a loosely coherent, scalable, distributed database with good performance and deployment -- but that doesn't mean that it should be overloaded to store $whatever - there is a complexity, scalability and monetary cost to running the system; it isn't a free, infinitely scalable resource, and we quickly get into a "tragedy of the commons" problem.


I have a few comments and questions related to this document:
1: "Address Block: IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890] (TBD6, suggested: 2001:30::/28)."
This seems like a *really* large block of addresses to be taking and using for this purpose - I understand that there is already some concern about the number of address bits being used for the crypto parts, but it does seem incredibly wasteful to be deciding to use this much of the IPv6 Special Purpose block for this -- there are only 32 /28s in the /23. Yes, IPv6 is large, but "no-one will need more that 640k of RAM", IPv4 was originally viewed as massive, etc --- this is 1,267,650,600,228,229,401,496,703,205,376 host addresses. 

2: I have some reservations about how much this punts a large amount of work to the DNS -- "Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications.", etc.  Has there been discussion with the DNSOP WG about the potential load profile? And with the IAB about having an entry under .arpa for this? This does feel somewhat like the well known "just put it in the DNS"-type solution (see slide 13 here). Yes, the DNS is an incredibly good, well scaling solution, but there are costs, and I think that more investigation into how this gets used without just shifting costs to someone else is needed. This is repeated in things like "A DET reverse lookup could be to: a69e.ad0.1952.a3ad.1405.280.30.2001.20.10.det.arpa. or: a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int." - yes, it *could* be, but this feels like it is assuming that .arpa or .icao.int is happy to serve this function, have the registry, etc.

Thanks for working on this specification.

I have following comments/observations, which I believe will improve this specification if addressed.

- Section 1: says -

        This addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP.

     this actually puts me off, how does a DRIP implementation use HHIT without using RFC7401 when this is all about extending and updating 7401? what are the other options the DRIP implementation can use instead of this? if there are any why do we need this specification? I simply can't understand the claims here.

- I noted that there is downref to  8032, was this indicated in the last call announcement?

- Section 8.2 is shy of giving proper guidance for "Expert review". It points to Section 4.5 of RFC8126 and that section says - 

     The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.

  I didn't find any such description.

- I also noted that there is lack of discussion on HHIT registration and validation technique. For this I am supporting Romans Discuss point of HHIT registration and validation.

Thanks for the document,

After reading the document I went through the other discuss points and they covered pretty much everything I had come up with and hence I support the other discusses, but with specific emphasis on Paul's discuss, as regards to making that zone mandatory and the failure situation that results.