Subject: [Drip] 2nd WGLC of draft-ietf-drip-arch (Ends 30/12/2021)

From: <[email-masked]>
Date: Thu, 16 Dec 2021 07:27:33 +0000

Hi all,

Given the changes made by the authors to address the issues raised in the first WGLC (03/21), we issue this second WGLC to let the WG review these changes.

The latest version to review is available at: https://datatracker.ietf.org/doc/draft-ietf-drip-arch/18/

For convenience, the changes made since the first WGLC can be tracked at: https://www.ietf.org/rfcdiff?url1=draft-ietf-drip-arch-11&url2=draft-ietf-drip-arch-18

If you have any issues or concerns with this version, please share them.

This call will last until December 30, 2021.

Cheers,
Daniel & Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 22 Dec 2021 17:53:50 -0500

Hi,

Thanks for posting this version, we are on track.

The document is informational and I can see some normative language. I
personally do not care and find it clearer but apparently it becomes
something the IESG looks at, so maybe our AD can provide some guidance
there.

Before submitting -19, please ensure that you run the nits check on the
datatracker.
Please find below the current nits reported by the datatracker for this
version.
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-drip-arch-18.txt

You can run it at the submission time.

To complete the shepherd write up I would need the following information:
1. Please let me know which known implementations
2. For each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed.

Please see my comments for this version.

Yours,
Daniel

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.

'''
I am wondering if 'and tracking' has not been added mistakenly. In fact it
seems strange to have (UAS RID) after as opposed to before 'and tracking'
and I could see tracking as one of the services associated to UAS RID.

The same text is copied in the introduction.

section 1.2.2

"""

[F3411 <https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-18#ref-F3411>],
using the same data dictionary that is the basis of
   Broadcast RID messages, defines a Network Remote Identification (Net-
   RID) data flow as follows.

"""

Unless I am missing it, I do not think the data dictionary has been defined
for the broadcast ID. I have the impression ''using the same data
dictionary that is the basis of Broadcast RID messages," could be removed.

I do not see GCS being shown in its expanded form. I propose it is expanded
in section 1.2.2.

 Figure 2
I am wondering if USS can be placed on the figure.
I have the impression DSS is a subpart of the Net-RID SP and more
especially the interface between the Net-RID SP and the Net-RID DP. I am
wondering if that is correct, and in any case if DSS may be represented on
the figure.
I am also wondering if there are any reasons to represent links without
orientation as opposed to directed links. I see that arrows might help
understand the description easier, while links are never totally
uni-directional.
It is a bit unclear to what the link (+) - (+) represents.
The figure uses NET-RID SP while the text uses Net-RID SP.

"""
Command and Control (C2) must flow from the GCS to the UA via some
   path, currently (in the year of 2021) typically a direct RF link, but
   with increasing beyond Visual Line of Sight (BVLOS) operations
   expected often to be wireless links at either end with the Internet
   between.
"""

I suspect there is nits and it could be "... operations, it is expected "
-- but I guess co-authors are more qualified to check the language.

The text also mentions "via some path" in the paragraph above and the
following one. I have the impression that is unnecessary information that
can be removed -- as if no path would exist the communication would not be
possible.

"""

 [F3411] prescribes the protocols between the Net-RID SP, Net-RID DP,
   and the Discovery and Synchronization Service (DSS).  It also
   prescribes data elements (in JSON) between Observer and Net-RID DP.
   DRIP could address standardization of secure protocols between the UA
   and GCS (over direct wireless and Internet connection), between the
   UAS and the Net-RID SP, and/or between the Net-RID DP and Observer
   devices.

"""

>From the figure I can see the link between SP and DP, but I am missing

where the DSS is and if there is another link.

The display of the informative note is strange. I do not see any reason for
having something different than a standard paragraph. This is just a
comment that can be fixed by the rfc editor.

section 1.3

DSS is expanded multiple times. I suggest expanding it once.

Figure 3: maybe for coherence, DSS may be mentioned together with SP in a
similar way as figure 2 -- with the additional DSS.

section 1.4

I am not sure the two bullet style is intentional.

Figure 4

I have the impression NetRID goes through SP/DP to some observers in this
case GP/PS OD or the other UAS. The figure may suggest that NetRID are
directly communicated by one UAS to the other. I am wondering if orienting
lightly the flows towards the observers might clarify the figure. Keep this
as a suggestion as I believed you went already through such suggestions.
I am also wondering if the registration link could be oriented toward the
registries.

section 3

"""

Self-asserting in this usage is given the Host Identity (HI), the
   HHIT ORCHID construction and a signature of the HHIT by the HI can
   both be validated.

"""
I suspect there is a english nits in "is given the" -- maybe "is given by
the ''.
I am wondering if any references should be added to  HI, HHIT ORCHID... I
have the impression that as we remain at a high level description and the
rid document is close to being ready that we can reference it for HHIT
ORCHID if needed.

section 3.1

I believe that mentioning cryptographic identifiers is sufficient.

"""

This
   means that given a sufficient collection of RID messages, an Observer
   can establish that the cryptographic identifier claimed therein

   uniquely belongs to
   the claimant

"""

I see the following text as necessary and can be removed:

"""
 that the only way for any other entity to prove
   ownership of that identifier would be to obtain information that
   ought to be available only to the legitimate owner of the identifier
   (e.g., a cryptographic private key).
"""

I suggest to split the following sentence for clarity.

"""

 Likewise, the
   maximum ASTM RID [F3411
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-18#ref-F3411>]
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.
"""

"""

Rather than using a key
   signing operation to claim ownership of an ID that does not guarantee
   name uniqueness, in this method the ID is cryptographically derived
   directly from the public key.

"""

 I believe the problem is more related to the way an ID is bound to the
key. It is also hard to guarantee no collision happens. I believe that
saying what we do is clearer than suggesting in a very unclear way what we
do not do. I would suggest to replace the following sentence by:

"""

In this method the ID is cryptographically derived
   directly from the public key.

"""

As I understand, this sentence repeats the one of the following paragraph
and can be removed. On the other hand we do not mention the ID as being the
HIT, so I would suggest to replace
 ""
OLD:
It is statistically hard for
   another entity to create a public key that would generate (spoof) the
   ID.

NEW:
The public key is designated as the HI while the ID is designated as the
HIT.
"""

"""
The basic HIT is designed statistically unique through the
   cryptographic hash feature of second-preimage resistance.
"""

The basic HIT seems to be the HIT, as it follows the description above I
would consider saying:
By construction, the HIT is statistically unique....

"""
The
   cryptographically-bound addition of the Hierarchy and an HHIT
   registration process (e.g. based on Extensible Provisioning Protocol,
   [RFC5730]) provide complete, global HHIT uniqueness.
"""

EPP is transparent to the registration process as far as I understand. I do
see this information more confusing and would recommend removing it.
The text does not explicitly mention why the registration results in a
unique HHIT. In my opinion the registration is for little as opposed to the
integration of that HIT into a centralized naming scheme that guarantees by
construction the uniqueness.

The following text does in my opinion add any information and should be
remove din my opinion.

"""

This
   registration forces the attacker to generate the same public key
   rather than a public key that generates the same HHIT.  This is in
   contrast to general IDs (e.g. a UUID or device serial number) as the

   subject in an X.509 certificate.
"""

"""
  Such a static HHIT SHOULD
   only be used to bind one-time use DRIP identifiers to the unique UA.
"""

This sentence is unclear to me - I suspect a nits.
While the current text is defining how an HHIT is defined, this sentence -
as I understand it - suggest a mechanism where an initial HHIT can assert
the another HHIT. If my understanding is correct it seems a bit out of
scope of that section and I would suggest to remove this comment.

The section is focused on describing the HHIT of the UA, so I suggest the
section finished with such description -- that is the UA and differ
comments concerning Observers, USS, providers.... to the end of the section
or at least after the paragraph "A self attesting ...."

"""

Each Observer
   device SHOULD be provisioned either with public keys of the DRIP
   identifier root registries or certificates for subordinate
   registries.

   HHITs can also be used throughout the USS/UTM system.  The Operators,
   Private Information Registries, as well as other UTM entities, can
   use HHITs for their IDs.  Such HHITs can facilitate DRIP security
   functions such as used with HIP to strongly mutually authenticate and
   encrypt communications.

"""

"""
A self-attestation of a HHIT used as a UAS ID can be done in as
   little as 84 bytes
"""

This is only valid with Ed25519, and not valid with any signature
algorithm. I think that needs to be specified.

section 3.3.

I have the impression we have been using RID, if so I would suggest to
change Remote ID to RID.

HHIT proof should mention the proof of what. It is probably proof of
ownership.

section 3.4

Maybe
s/within which is registered/within which it is registered

section 4.1.1

"""

 (e.g., for HDA and RAA
   HHIT|HI used in attestation signing operations)

"""

I am unsure if I understand it correctly. Is the

intention to say that HDA and RAA are identified by

HHIT or HI ?

4.1.2

(e.g.  DNS   over TLS) currently most DNS over TLS

have been defined for resolvers. I do not necessarily

 see an issue of carrying a DNS packet in TLS, but DNSSEC actually
does what you are mentioning.

I suggest adding DNSSEC and be prepared to receive some comments
regarding the DNS over TLS.

section 5

"""and be actively
   used by the party (in most cases the UA)."""

I believe we need to understand why it needs to be actively used and
what actively used means.

" without Internet connection (offline) or with (online)," sounds to
me like A or non A which is always true. I would suggest to remove
this text.

The text introduces a lot of new terminology that needs some explanation.

 """

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

"""

section 6

On Thu, Dec 16, 2021 at 2:27 AM <[email-masked]> wrote:

> Hi all,
>
>
>
> Given the changes made by the authors to address the issues raised in the
> first WGLC (03/21), we issue this second WGLC to let the WG review these
> changes.
>
>
>
> The latest version to review is available at:
> https://datatracker.ietf.org/doc/draft-ietf-drip-arch/18/
>
>
>
> For convenience, the changes made since the first WGLC can be tracked at:
> https://www.ietf.org/rfcdiff?url1=draft-ietf-drip-arch-11&url2=draft-ietf-drip-arch-18
>
>
>

-- 
Daniel Migault
Ericsson

---

From: Andrei Gurtov <[email-masked]>
Date: Fri, 31 Dec 2021 17:31:17 +0100

Hi,

FYI, EU published a new document "Development of acceptable means of 
compliance and guidance material to support the U-space regulation" that 
also makes changes regarding remote/network drone ID.

https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-2021-14

br Andrei

On 16-Dec-21 8:27, [email-masked] wrote:
>
> Hi all,
>
> Given the changes made by the authors to address the issues raised in 
> the first WGLC (03/21), we issue this second WGLC to let the WG review 
> these changes.
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-drip-arch%2F18%2F&data=04%7C01%7Candrei.gurtov%40liu.se%7Cbd707b7e4c0a430e7a8908d9c06591d4%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637752365484357623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=a5l7aDM%2FDoyl1Kg1qmdjFISlmfTShK3HFmikhpsPqs8%3D&reserved=0>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-drip-arch-11%26url2%3Ddraft-ietf-drip-arch-18&data=04%7C01%7Candrei.gurtov%40liu.se%7Cbd707b7e4c0a430e7a8908d9c06591d4%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637752365484357623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0WLz23gwhRWRLkyw3MYmN7Hr2AyeYtIiuv8LAeGaKz8%3D&reserved=0> 
>
>