Subject: Re: [Drip] I-D Action: draft-ietf-drip-arch-05.txt

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 09:17:39 -0500

Now on to sec 5....

After an exchange with Stu Card, I am strengthening my argument for 
limiting information in the public registry to trustable data, as I do 
not believe (unless someone can demonstrate it) that DNSSEC is a viable 
security solution and that DNS over TLS also falls short, as it is TLS 
to the Observer's server, not necessarily the one that is the public 
registry for the RID.

On 11/3/20 10:03 AM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Drone Remote ID Protocol WG of the IETF.
>
> Title : Drone Remote Identification Protocol (DRIP) Architecture
> Authors : Stuart W. Card
> Adam Wiethuechter
> Robert Moskowitz
> Shuai Zhao
> Andrei Gurtov
> Filename : draft-ietf-drip-arch-05.txt
> Pages : 23
> Date : 2020-11-03

In Sec 5:

    UAS registries hold both public and private UAS information.  The
    public information is primarily pointers to the repositories of, and
    keys for looking up, the private information.  Given these different
    uses, and to improve scalability, security and simplicity of
    administration, the public and private information can be stored in
    different registries, indeed different types of registry.

Change to:

5. DRIP HHIT RID registration and registries

     The DRIP HHIT RID registration goes beyond what is currently 
envisioned in
     UTM for the UAS to USS registration/subscription process.

    UAS registries hold both public and private UAS information resulting
    from the UAS RID registration.  Given these different
    uses, and to improve scalability, security and simplicity of
    administration, the public and private information can be stored in
    different registries, indeed different types of registry.

I think sec 5.1 and 5.2 should be switched.  We should have discussion 
on Public Information Registry before Private, as Private expands on Public.

So I will construct my comments as if this change was made.

WRT to DRIP and Public Registry, I pretty much totally disagree with the 
first paragraph in 5.2.1 Background.

Registry excludes operation information from the Broadcast messages; it 
is the 'job' of the UTM to make such information publicly available.  
Also the Public Registry as a serious trust challenge. How is the 
information assured not to be spoofed?

The public registry information, keyed off the RID, is the RID 
attestation information.  This is:

The HI behind the HHIT.
The RAA and HDA for the RID; but this information is implicit in the RID 
and RAA and HDA lookups SHOULD be directly possible with just this 
information.  No PTR or other registry information should be necessary.
The HHIT self attestation.
The HDA proof of registration attestation.

The fact that the public registry provides the HI for a HHIT might be 
sufficient proof of HI private key ownership by the registering entity 
(e.g. UA) and registration with the HDA.  But it should be stated in as 
part of the public information.

there is some interesting debate about public broadcast information like 
the content of the Self-ID message (hello, I am a local realtor taking 
pics of a property I want to sell) and Operator information (ID and 
location) if not protected as PII (see operator-privacy draft for 
initial 'rules' of when this is private).

The casual observer may not have a subscription with a USS and thus may 
not have a 'view' into this information as an authenticated USS user 
would.  But IMHO, this is UTM information, and an observer, after 
getting the public registry information, can then query the UTM for all 
this and other public data.

This is the dichotomy I see between public registry information and 
public UTM information.

That all said, let's get back to sec 5...

5.1 Public Information Registry

5.1.1 Background

   The public registry provides trustable information such as 
attestations of RID ownership and HDA registration.  Optionally, 
pointers to the repositories for the HDA and RAA implicit in the RID can 
be included (e.g. for HDA and RAA HHIT|HI used in attestation signing 
operations).  This public information will principally used by observers 
of Broadcast RID messages.  Data on UAS that only use Network RID, is 
only available via an observer's Net-RID DP that would tend to directly 
provide all public registry information directly.  The observer may 
visually 'see' these UAS, but they are silent to the observer; the 
Net-RID DP is the only source of information based on a query for a 
airspace volume.  Thus there is no need for information on them in a 
Public Registry.

5.1.2.  Proposed Approach

    A DRIP public information registry MUST respond to standard DNS 
queries, in
    the definitive public Internet DNS hierarchy.  It MUST support NS,
    MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005])
    types.  If a DRIP public information registry lists, in a HIP RR, any
    HIP RVS servers for a given DRIP UAS ID, those RVS servers MUST
    restrict relay services per AAA policy; this may require extensions
    to [RFC8004].  These public information registries SHOULD use secure 
DNS transport
    (e.g. DNS over TLS) to deliver public information which is not 
inherently trustable
    (e.g. everything other than attestations).

Move CS-RID, I will attempt to figure out where it goes.  It does not 
provide updates to Public Information Registry information, rather 
information for Net-RID DP.

5.2.  Private Information Registry

5.2.1.  Background

The private information required for DRIP RID is similar to that 
required for Internet domain name registration.  This information SHOULD 
be available for ALL UAS, including those that only use Network RID.  A 
DRIP RID solution can leverage existing Internet resources: registration
    protocols, infrastructure and business models, by fitting into an ID
    structure compatible with DNS names.  This implies some sort of
    hierarchy, for scalability, and management of this hierarchy.  It is
    expected that the private registry function will be provided by the
    same organizations that run USS, and likely integrated with USS.

5.2.2.  Proposed Approach

    A DRIP RID MUST be amenable to handling as an Internet domain name
    (at an arbitrary level in the hierarchy), MUST be registered in at
    least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be
    registered as a sub-domain (for forward lookup).  This DNS information
    MAY be protected with DNSSEC.  Its access SHOULD be protected with a
    secure DNS transport (e.g. DNS over TLS).

    A DRIP private information registry MUST support essential Internet
    domain name registry operations (e.g. add, delete, update, query)
    using interoperable open standard protocols.  It SHOULD support the
    Extensible Provisioning Protocol (EPP) and the Registry Data Access
    Protocol (RDAP) with access controls.  It MAY use XACML to specify
    those access controls.  It MUST be listed in a DNS: that DNS MAY be
    private; but absent any compelling reasons for use of private DNS,
    SHOULD be the definitive public Internet DNS hierarchy.  The DRIP
    private information registry in which a given UAS is registered MUST
    be findable, starting from the UAS ID, using the methods specified in
    [RFC7484].  A DRIP private information registry MAY support WebFinger
    as specified in [RFC7033].

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 09:57:29 -0500

Now on to the CS-RID stuff...

Oops.  As I look at where to put CS-RID, I see that sec 6 needs to be 
before sec 4.  It makes no sense, organizationally where it is right now.

So:

Move sec 6 to sec 4.

Move sec 4 & 5 down to 5 and 6 respectively.

Next back to CS-RID.  :)

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 10:50:09 -0500

Now really on to the CS-RID stuff...

Oh, I changed the subject line to reflect arch-06.  The prior two 
missives also are on arch-06 (these sec not changed from arch-05).

CS-RID becomes a new sec 7, pushing everything else down a sec.

7.  Harvesting Broadcast Remote ID messages for UTM inclusion

    ASTM anticipated that regulators would require both Broadcast RID and
    Network RID for large UAS, but allow RID requirements for small UAS
    to be satisfied with the operator's choice of either Broadcast RID or
    Network RID.  The EASA initially specified Broadcast RID for UAS of
    essentially all UAS and is now also considering Network RID.  The FAA
    NPRM requires both for Standard RID and specifies Network RID only
    for Limited RID.

    One obvious opportunity is to enhance the
    architecture with gateways from Broadcast RID to Network RID. This
    provides the best of both and gives regulators and operators
    flexibility.  It offers considerable enhancement over some Network RID
    options such as only reporting planned 4D operation space by the 
operator.

    These gateways could be pre-positioned (e.g. around
    airports, public gatherings, and other sensitive areas) and/or 
crowdsourced (as nothing
    more than a smartphone with a suitable app is needed).  As Broadcast
    RID media have limited range, gateways receiving messages claiming
    locations far from the gateway can alert authorities or a SDSP to the
    failed sanity check possibly indicating intent to deceive.
    Surveillance SDSPs can use messages with precise date/time/position
    stamps from the gateways to multilaterate UA location, independent of
    the locations claimed in the messages (which may have a natural time lag
    as it is), which are entirely operator
    self-reported in UAS RID and UTM.  Further, gateways with additional
    sensors (e.g. smartphones with cameras) can provide independent
    information on the UA type and size, confirming or refuting those
    claims made in the RID messages.  This Crowd Sourced Remote ID
    (CS-RID) would be a significant enhancement, beyond baseline DRIP
    functionality; if implemented, it adds two more entity types.

7.1.  The CS-RID Finder

    A CS-RID Finder is the gateway for Broadcast Remote ID Messages into
    the UTM.  It performs this gateway function via a CS-RID SDSP.  A CS-RID
    Finder must implement, integrate, or accept outputs from, a 
Broadcast RID
    receiver.  It MUST NOT interface directly with a GCS, Net-RID SP, Net-
    RID DP or Network RID client.  It MUST present a TBD interface to a 
CS-RID SDSP; this
    interface SHOULD be based upon but readily distinguishable from that
    between a GCS and a Net-RID SP.

7.2.  The CS-RID SDSP

    A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net-
    RID SP as a Net-RID DP.  A CS-RID SDSP MUST appear to a Net-RID DP as
    a Net-RID SP.  A CS-RID SDSP MUST NOT present a standard GCS-facing
    interface as if it were a Net-RID SP.  A CS-RID SDSP MUST NOT present
    a standard client-facing interface as if it were a Net-RID DP.  A CS-
    RID SDSP MUST present a TBD interface to a CS-RID Finder; this
    interface SHOULD be based upon but readily distinguishable from that
    between a GCS and a Net-RID SP.

I think I got this basically right...

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 12:45:22 -0500

Just keep on rolling along...

What was sec 7 (now 8) needs some introduction.  It just hits assuming 
some things.  So...

The text is just too dense to follow, so more paragraphs.  Using lists 
opens it up for readability.

8.  DRIP Transactions enabling Trustworthy

    The UTM (U-SPACE) architecture leaves much about all the 
operators/UAS to
    the various USS.  Each CAA will have some registration requirements on
    operators (FAA part 105 is considered very minimal by some CAA), along
    with some UAS and operation registration.  DRIP leverages this model 
with
    Identities for each component that augment the DRIP RID and transactions
    to support these Identities.

    To this end, in DRIP, each Operator MUST generate a Host Identity of the
    Operator (HIo) and derived Hierarchical HIT of the Operator (HHITo).
    These are registered with a Private Information Registry along with
    whatever Operator data (inc.  PII) is required by the cognizant CAA
    and the registry.  In response, the Operator will obtain a Certificate
    from the Registry, an Operator (Cro), signed with the Host Identity of
    the Registry private key (HIr(priv)) proving such registration.

    An Operator may now 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.

    The operator then MUST provision the UA with HIa, HIa(priv), HHITa 
and Cra.

      *  UA engaging in Broadcast RID MUST use HIa(priv) to sign Auth 
Messages
          and MUST periodically broadcast Cra.

       *  UAS engaging in Network RID MUST use HIa(priv) to sign Auth 
Messages.

      *  Observers MUST use HIa from received Cra to verify received 
Broadcast RID
        Auth messages.

      *   Observers without Internet connectivity MAY use Cra to 
identify the
          trust class of the UAS based on known registry vetting.

      *  Observers with Internet connectivity MAY use HHITa to perform 
lookups in the
         Public Information Registry
         -  and MAY then query the Private Information Registry
       -   which MUST enforce AAA policy on Operator PII and other 
sensitive information

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 12:58:31 -0500

And finally sec 8 (now 9)

To the editor's note:

    Editor's ntoe: move this to a subsction of Operator Privacy?

I don't see such a section to move this too.  It does not belong in the 
Security Considerations section...

A separate point is we have both "operatior" and "Operator".  Do we need 
to be consistent on capitalization usage?  I have not tried to fix that 
here.

So.

9.  Privacy for Broadcast PII

    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
    position (consistent with, e.g., the EU General Data Protection
    Regulation) is to hide PII unless otherwise instructed.  While some
    have argued that a system like that of automobile registration plates
    should suffice for UAS, others have argued persuasively that each
    generation of new identifiers should take advantage of advancing
    technology to protect privacy, to the extent compatible with the
    transparency needed to protect safety.

    A viable architecture for PII protection would be symmetric
    encryption of the PII using a key known to the UAS and its USS.
    An authorized Observer may send the encrypted PII along with the
    Remote ID (to their UTM Service Provider) to get the plaintext.
    Alternatively, the authorized Observer may receive the key to
    directly decrypt all future PII content from the UA.

    PII SHOULD protected unless the UAS is informed otherwise.  This may 
come
    from operational instructions to even permit flying in a space/time.
    It may be special instructions at the start or during an operation.
    PII protection should not be used if the UAS loses connectivity to
    the USS.  The UAS always has the option to abort the operation if PII
    protection is disallowed.

    An authorized observer may instruct a UAS via the USS that conditions
    have changed mandating no PII protection or land the UA (abort the 
operation).

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 13:04:18 -0500

And finally:

In IANA considerations the practice is just have

TBD

everyone 'knows' this is a placeholder.  And give this is an 
architecture document, this section may well be cut.

In Security Considerations.

Drop the 1st sentence.  This section is about what security concerns 
there are with the document.  What was left out?  What might the 
weaknesses be?  So 1st sentence goes.

Otherwise, leave the rest.

And this completes my comments on drip-arch.

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Mon, 21 Dec 2020 19:17:19 +0000

Thanks Bob, so far I have got 5 emails with detailed comments. Thank you for that. I will implement those in next revision.

Best,
Shuai Zhao

From: Tm-rid <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Date: Monday, December 21, 2020 at 10:04
To: "[email-masked]" <[email-masked]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-arch-06.txt(Internet mail)

And finally:

TBD

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Dec 2020 14:48:37 -0500

I sent 6 today.

And this completes my review.  For now.

On 12/21/20 2:17 PM, shuaiizhao(Shuai Zhao) wrote:
>
> Thanks Bob, so far I have got 5 emails with detailed comments. Thank 
> you for that. I will implement those in next revision.
>
> Best,
>
> Shuai Zhao
>
> *From: *Tm-rid <[email-masked]> on behalf of Robert Moskowitz 
> <[email-masked]>
> *Date: *Monday, December 21, 2020 at 10:04
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Drip] I-D Action: draft-ietf-drip-arch-06.txt(Internet 
> mail)
>
> And finally:
>
> [email-masked] <mailto:[email-masked]>
>
> <https://www.ietf.org/mailman/listinfo/tm-rid>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 21 Dec 2020 18:51:28 -0500

There is a distinction between information that MUST, SHOULD or MAY be
placed in a public registry for various purposes.
E.g. a DNS PTR record enabling a reverse lookup of a FQDN may often be
useful, even if not always needed; likewise records enabling SIP to be used
to call the operator.
For such optional information, we may not need to set the security bar
higher than it is for similar information in DNS supporting applications
other than UAS RID.
For the HHIT/HI/HDA/RAA bindings etc. we need strong cryptographic
assurances as Bob has proposed.

On Mon, Dec 21, 2020 at 9:18 AM Robert Moskowitz <[email-masked]>
wrote:

> [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 23 Dec 2020 08:20:38 -0500

One last piece.  For now...

the following is from draft-wiethuechter-drip-identity-claims, and it 
becomes sec 3.3 in drip-arch.  I only changed the first sentence...

3.3.  Claims, Assertions, Attestations, and Certificates

    There is a clear distinction on exactly what these terms mean in the 
context of DRIP.

    This is due, in part, to the term "certificate" having significant 
technologic
    and legal baggage associated with it, specifically around X.509
    certificates.  These type of certificates and Public Key
    Infrastructure invokes more legal and public policy considerations
    than probably any other electronic communication sector.  It emerged
    as a governmental platform for trusted identity management and was
    pursued in intergovernmental bodies with links into treaty
    instruments.

    As such the following terms are being used in DRIP.

3.3.1.  Claims

    For DRIP claims are used in the form of a predicate (X is Y, X has
    property Y, and most importantly X owns Y).  The basic form of a
    claim is an entity using a HHIT as an identifier in the DRIP UAS
    system.

3.3.2.  Assertions

    Assertions, under DRIP, are defined as being a set of one or more
    claims.  This definition is borrowed from JWT/CWT.  An HHIT in of
    itself can be seen as a set of assertions.  First that the identifier
    is a handle to an asymmetric keypair owned by the entity and that it
    also is part of the given registry (specified by the HID).

3.3.3.  Attestations

    An attestation is a signed claim.  The signee may be the claimant
    themselves or a third party.  Under DRIP this is normally used when a
    set of entities asserts a relationship between them along with other
    information.

3.3.4.  Certificates

    Certificates in DRIP have a narrow definition of being signed
    exclusively by a third party and are only over identities.

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Mon, 28 Dec 2020 04:39:15 +0000

As a side note, there is no absolute security for either public or private registry. In the general aviation world, everyone can hold a VHF radio and talk, there is no direct/immediate way to block anyone to act as an ATC. And it just works. Let the law enforcement figure out how to deal with those who do not follow the rules. That being said, I kinda agree with Stu that using proper MUST/SHOULD/MAY for optional operations.

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Monday, December 21, 2020 at 15:52
To: Robert Moskowitz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-arch-05.txt(Internet mail)

There is a distinction between information that MUST, SHOULD or MAY be placed in a public registry for various purposes.
E.g. a DNS PTR record enabling a reverse lookup of a FQDN may often be useful, even if not always needed; likewise records enabling SIP to be used to call the operator.
For such optional information, we may not need to set the security bar higher than it is for similar information in DNS supporting applications other than UAS RID.
For the HHIT/HI/HDA/RAA bindings etc. we need strong cryptographic assurances as Bob has proposed.

On Mon, Dec 21, 2020 at 9:18 AM Robert Moskowitz <[email-masked]<mailto:[email-masked]>> wrote:
Now on to sec 5....

In Sec 5:

Change to:

The HI behind the HHIT.

5.1.1 Background

5.1.2.  Proposed Approach

5.2.1.  Background

5.2.2.  Proposed Approach