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

From: [email-masked]
Date: Mon, 25 Oct 2021 12:18:06 -0700

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-16.txt
	Pages           : 26
	Date            : 2021-10-25

Abstract:
   This document describes an architecture for protocols and services to
   support Unmanned Aircraft System Remote Identification and tracking
   (UAS RID), plus RID-related communications.  This architecture
   adheres to the requirements listed in the DRIP Requirements document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-arch/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-16

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 29 Oct 2021 15:41:18 -0400

in 1.2:

We just had fig 2 showing the Observer communicating with the Net-RID 
DP, then say:

It also prescribes data elements (in JSON) between Observer and USS

I think that needs to be Net-RID DP.

An Observer may well not have any relationship with any USS, though 
Net-RID DP may well be a service provided within many USS systems.

in 1.3:

Where does "Surveillance Supplemental Data Service Provider (SDSP)" come 
from?  It is only mentioned here.  I do not see this term in F3411-19 or 
in WK63418 UAS Traffic Management (UTM) UAS Service Supplier (USS) 
Interoperability Specification ver 0.4.1 (in ballot).  SDSP normally 
means Supplemental Data Service Provider, so here it probably should be 
SSDSP?

Also we need to add that these SSD

I like the term and should "upgrade" from just SDSP in crowd-source-rid?

Should, can we, reference a source for this concept?

Sec 3:

Should this really be sec 2.4?  Its content is Definitions of terms.

Seems I mentioned this in past reviews.

Sec 4.1:

We are in a bit of a timing quandary, in that we can only reference 
F3411-19, yet need to talk about the next version currently being 
balloted.  This will either be F3411-21 or -22 (and interesting if they 
quickly get the NEXT work item down and end up with TWO -22 versions!).

Since we cannot reference ASTM draft documents (not unlike IEEE 802, 
actually), how do we handle this?  I think we need some clarifying text 
that the text here is about a draft version; we cannot provided any 
information on its likelihood of being published.

Also we may well have this RFC published prior to F3411-21!

So:

Broadcast RID, especially its support for Bluetooth 4, imposes severe
constraints.  ASTM RID [F3411-19] allows a UAS ID of types 1, 2 and 3 of
20 bytes; a revision to [F3411-19], currently in balloting (as of Oct 
2021),
adds type 4, Session IDs, to be
standardized by IETF and other standard development organizations
(SDOs) as extensions to ASTM RID, consumes one of those bytes
to index the sub-type, leaving only 19 for the identifier (see
Requirement ID-1).  Likewise, the maximum ASTM RID [F3411-19]
Authentication Message payload is 201 bytes for most authentication
types, but for type 5, also added in this revision, for IETF and other 
SDOs to develop
Specific Authentication Methods as extensions to ASTM RID, one
byte is consumed to index the sub-type, leaving only 200 for DRIP
authentication payloads, including one or more DRIP entity
identifiers and associated authentication data.

4.2:

    A UAS equipped for DRIP Broadcast RID SHOULD be provisioned not only 
with
    its HHIT but also with the HI key pair from which the HHIT was
    derived to enable message
    signature.  A UAS equipped for DRIP Network RID SHOULD be provisioned
    likewise; the private key resides only in the ultimate source of
    Network RID messages (i.e. on the UA itself if the GCS is merely
    relaying rather than sourcing Network RID messages).  Each Observer
    device SHOULD be provisioned either with public keys of the DRIP
    identifier root registries or certificates for subordinate
    registries.

And I think that first "UAS" should be "UA".

    A self-attestation of a HHIT used as a UAS ID can be done in as
    little as 84 bytes, by avoiding an explicit encoding technology like
    ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This
    attestation consists of only the HHIT, a timestamp, and the EdDSA
    signature on them.

I should point out that though this is true, Adam, Stu, and I are 
debating the 'final' format (Adam 36 bytes to this).  I feel this is 
correct for the architecture.

    A DRIP registration process based on the explicit hierarchy within a
    HHIT provides manageable uniqueness of the HI for the HHIT (defense
    against a cryptographic hash second pre-image attach on the HHIT
    (e.g. multiple HIs yielding the same HHIT, see Requirement ID-3).  A
    lookup of the HHIT into this registration data provides the
    registered HI for HHIT proof.  A first-come-first-serve registration
    for a HHIT provides deterministic access to any other needed
    actionable information based on inquiry access authority (more
    details in Section 5.2).

/s/attach/attack/  It was correct in -15.

You have parenthesis nested within parenthesis above and it is 
confusing.  Instead:

    A DRIP registration process based on the explicit hierarchy within a
    HHIT provides manageable uniqueness of the HI for the HHIT.  This is 
the defense
    against a cryptographic hash second pre-image attack on the HHIT
    (e.g. multiple HIs yielding the same HHIT, see Requirement ID-3).  A
    lookup of the HHIT into this registration data provides the
    registered HI for HHIT proof.  A first-come-first-serve registration
    for a HHIT provides deterministic access to any other needed
    actionable information based on inquiry access authority (more
    details in Section 5.2.

sec 4.4

Minor edit:

    hierarchy within which is registered and a cryptographic hash of

I think I got that right....

At this point I am stopping and will pick up shortly with sec 5.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 31 Oct 2021 17:41:56 -0400

Continuing with Sec 5.

All is good IMO in sec 5.

Sec 6.

Para 2:

Would a reader know what "offline or online" mean?  This is the first 
and only use of both terms.  So we need to actually define them here.

Also I do not think Broadcast RID needs to send messages that 
authenticate all the way to the root.  This is rarely done in other 
protocols.  Having something signed by the HDA and the HDA's HHIT,HI is 
necessary, but sufficient along with access to a cache of the rest of 
the hierarchy.  Similar to web browser CA root cache and DNS root cache.

so

    An optimization of different DRIP Authentication Messages allows an
    Observer, without Internet connection (offline) or with (online), to be
    able to validate a UAS DRIP ID in real-
    time.  First is the sending of Broadcast Attestations (over
    DRIP Link Authentication Messages) containing the relevant registration
    of the UA's DRIP ID in the claimed Registry.  Next is
    sending DRIP Wrapper Authentication Messages that sign over
    both static (e.g. above registration) and dynamically changing data
    (such as UA location data).  Combining
    these two sets of information an Observer can piece together a chain
    of trust and real-time evidence to make their determination of the
    UAs claims.

Sec 7

In 1.3, we used: Surveillance Supplemental Data Service Provider

We should follow through with that class of SDSP here or drop it in 1.3.

And in 7.2 perhaps:

    A CS-RID SDSP should appear (i.e. present the same interface) to a
    Net-RID SP as a Net-RID DP.  A CS-RID SDSP aggregates and processes
    (e.g., estimates UA location using including using multilateration when
    possible) information collected by CS-RID Finders.

Sec 8.

One of the ways in which DRIP can enhance [F3411-19] with

============

And that completes my review.

Bob