Subject: [Drip] comments on drip-arch-03

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Aug 2020 22:10:02 -0400

These comments are on arch-03.
I was watching the video, and got to "Stu's own Questions/concerns" slide,
and felt that this was a good point to move from "have not read drafts" to
"have read drafts" state.

First, I don't like the stick-people ade of x.  One can't see their smiling faces!
"There are all dead" / "Everybody's Dead" (so many memes beyond Red Dwarf)
Removing those x and just using a small box would let you include a Network
RID (direct from the UA and also relayed via GCS), and Broadcast RID.
Also: https://metacpan.org/pod/App::Asciio (apt-get install asciio)

Expand ASTM first time please.
   [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking",
              December 2019.
   I know it costs money to buy, but URL for the entire effort? Surely, the
   F38.02 subcmte has a web site somewhere, or at least a wikipedia entry?

---
   If a UAS uses both communication methods, generally the same
   information must provided via both means.  While hybrids are possible
   (and indeed one is proposed as an optional DRIP service), the two
   basic methods are defined as follows:

Could you tell us about the hybrid after you've told us about the two
options?  Or just make that a third option.
I suggest Network RID be a subsection with a diagram.
Emphasis that this is ASTM content that you are repeating/paraphrasing.

I think that jumping into Network RID/Broadcast RID in section 1.0 is too
soon, and there are many TLAs that, while in the reqs document, the reader
does not yet really know that they come from there.

   This document will outline the UAS RID architecture into which DRIP
   must fit, and an architecture for DRIP itself.  This includes
   presenting the gaps between the CAAs' Concepts of Operations and
   [F3411-19] as it relates to use of Internet technologies and UA
   direct RF communications.  Issues include, but are not limited to:

I would move this up to just after:
   ASTM [F3411-19] Standard Specification for Remote ID and Tracking.

and I'd move all the rest of the details further down.  Where I don't know
yet.

CHANGE:
   Issues include, but are not limited to:
   *  Trustworthy Remote ID and trust in RID messages
   *  Privacy in RID messages (PII protection)
   *  UA -> Ground communications including Broadcast RID
   *  Broadcast RID 'harvesting' and secure forwarding into the UTM
   *  Secure UAS -> Net-RID SP communications
   *  Secure Observer -> Pilot communications

To:
   Design aspects covered in this document include:
   * mechanisms to leverage Domain Name System (DNS: RFC1034) and Extensible
   Provisioning Protocol (EPP: RFCxxx) technology to provide for an
   Information Registry. (section 3.1, 3.2)
   *  Trustworthy Remote ID and trust in RID messages (section 5)
   *  Privacy in RID messages (PII protection) [section 6]
   ** Architectural accomodation for differences between FCC and EASA Requirements [section 7]
   *  UA -> Ground communications including Broadcast RID
   *  Broadcast RID 'harvesting' and secure forwarding into the UTM
   *  Secure UAS -> Net-RID SP communications
   *  Secure Observer -> Pilot communications

{I expected to come back and edit section numbers into the last few stars,
but I didn't really find the right places. That's a bug.  The goal here is
foreshadowing to set expectations, but also, for some readers, the point
is establish what is *NOT* in this document, so that they go to the next
google hit...}

I think that it would be nice if the various abstractions like CAA could be
turned into a story, perhaps set in some fantasy land like Lilliput, where
all the involved actors have silly company names, rather than TLAs.

Section 3.1/3.2 needs to get rewritten.   We don't need to say "MUST support X,Y"
we need to how we intend to use DNS, and there probably should be a document
that is the implementation document for how to use EPP and DNS.

section 3.3 CS-RID seems come out of the blue here.
section 3.3.1 has too many TLAs. Net-RID DP is a poor TLA too.
Maybe nrDP, but I'd rather remove "Provider" from the TLA.
People get bent out of shape dealing with "DNS" not being "Domain Name Server",
(but, System), so having a DNS Server makes sense, but...
So I suggest nRID-Serv and nRID-Aggr (rather than Display).

Does CS-RID significant alter the architecture that it needs to be discussed
so early?  Could it go into a separate document as an extension?  It seems
like it is designed to drop into between the NetRID-DS[nRID-Aggr] and NetRID-SP[nRID-Serv]
interfaces without either caring.

>   HITs for UAS RID is outlined in HHIT based UAS RID [drip-uas-rid].

This is a document which is not yet adopted, right?
That's fine.  I think that the salient properties of HHITs need to be
explained in two paragraphs.  Why not PKI should not be the point *HERE*, but
rather to explain what you are doing, rather than what you are not.

>   and the UTM InterUSS protocol) mappings between the more flexible but
>   larger X.509 certificates and the HHIT based structures must be
>   devised.

readings like a requirement, move it to reqs.
here, it should be explained how they *can* be mapped.
The simplest I think of is with DTLS RRs in the DNS used by HHITs,
and with a X.509 SAN that contains the HHIT.

>   A DRIP UAS ID MUST be a HHIT.  It SHOULD be self-generated by the UAS
>   (either UA or GCS) and MUST be registered with the Private
>   Information Registry identified in its hierarchy fields.  Each UAS ID

Architectures are usually informational, so generally BCP14 language is not
used. (I don't entirely agree with this myself)

I would write instead:
    The DRIP UAS architecture defines the UAS ID to be a HHIT.
    The UAS self-generates the HHIT (see section Foo of [BAR]),
    and using the EPP protocol as describe in section Baz of [BAR],
    it registers its public and private information.
    This results in a HHIT being published into DNS in ...

    >Insert example<

    4.2.2 Static HHIT.
    4.2.3 Use with Broadcast RID

Section 5.

This is one sentence:

   To add an UA, an Operator MUST generate a Host Identity of the
   Aircraft (HIa) and derived Hierarchical HIT of the Aircraft (HHITa),
   create a Certificate from the Operator on the Aircraft (Coa) signed
   with the Host Identity of the Operator private key (HIo(priv)) to
   associate the UA with its Operator, register them with a Private
   Information Registry along with whatever UAS data is required by the
   cognizant CAA and the registry, obtain a Certificate from the
   Registry on the Operator and Aircraft ("Croa") signed with the
   HIr(priv) proving such registration, and obtain a Certificate from
   the Registry on the Aircraft (Cra) signed with HIr(priv) proving UA
   registration in that specific registry while preserving Operator
   privacy.

I would expect either a narrative, or section numbers.

6. Privacy.

   Broadcast RID messages may contain PII.  This may be information
   about the UA such as its destination or Operator information such as
   GCS location.  There is no absolute "right" in hiding PII, as there
   will be times (e.g., disasters) and places (buffer zones around
   airports and sensitive facilities) where policy may mandate all
   information be sent as cleartext.  Otherwise, the modern general

It seems to me that places like buffer zones around airports ought to
broadcast some kind of signed statement saying that there is a policy about
privacy.  And places where they shoot first and ask after.
I suspect that this is not in the ASTM model, so can't be added.
There are probably installations which do not want drones, yet don't want reveal
that they are present.  It seems that this section should explain this more.

   A viable architecture for PII protection would be symmetric
   encryption of the PII using a key known to the UAS and a USS service.

yes, that might be viable... is it in the architecture or not :-)

section 7 seems to provide for compliance.
This belongs in an appendix, possibly in another document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-