Subject: [Drip] I-D Action: draft-ietf-drip-reqs-04.txt

From: [email-masked]
Date: Tue, 25 Aug 2020 20:06:17 -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) Requirements
        Authors         : Stuart W. Card
                          Adam Wiethuechter
                          Robert Moskowitz
                          Andrei Gurtov
	Filename        : draft-ietf-drip-reqs-04.txt
	Pages           : 30
	Date            : 2020-08-25

Abstract:
   This document defines the requirements for Drone Remote
   Identification Protocol (DRIP) Working Group protocols to support
   Unmanned Aircraft System Remote Identification and tracking (UAS RID)
   for security, safety and other purposes.  Complementing external
   technical standards as regulator-accepted means of compliance with
   UAS RID regulations, DRIP will:

      facilitate use of existing Internet resources to support UAS RID
      and to enable enhanced related services;

      enable online and offline verification that UAS RID information is
      trustworthy.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-drip-reqs-04
https://datatracker.ietf.org/doc/html/draft-ietf-drip-reqs-04

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: "Card, Stu" <[email-masked]>
Date: Tue, 25 Aug 2020 23:15:44 -0400

My apologies to everyone for the 11th hour (literally) submission and to
Daniel for my failure to understand thus address as yet several of the
points in his extensive review.

what I did & didn't do:
(0) did attempt to address every point raised by reviewers (to the extent I
thought I understood them);
(1) didn't take suggestions apparently due to reviewer lacking UAS context,
instead added missing context;
(2) didn't take suggestions apparently lacking consensus (but will if
raised again & WG expresses consensus);
(3) didn't remove definitions of terms likely to be used in other DRIP
documents (but will if the WG prefers);
(4) didn't substantially restructure the document (but will if the WG
prefers);
(5) didn't do all the minor corrections & final proofreading (yet).

review question from Michael R.: Should GEN-1 be exploded into multiple
numbered requirements?
(a) message integrity / non-repudiation
(b) defense against replay attacks
(c) defense against spoofing
(d) connected to a sender public key (related to GEN-3)
(e) Observer w/o Internet at time of observation

My slides will be limited to the points above and the actual numbered
requirements text, focusing on the previously debated PRIV-2 and PRIV-3
plus the newly added (based on reviewers' comments) PRIV-4 and PRIV-5.

Thanks. Good night!

On Tue, Aug 25, 2020 at 11:06 PM <[email-masked]> wrote:

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

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 26 Aug 2020 07:55:27 -0400

On 8/25/20 11:15 PM, Card, Stu wrote:
> My apologies to everyone for the 11th hour (literally) submission and 
> to Daniel for my failure to understand thus address as yet several of 
> the points in his extensive review.
>
> what I did & didn't do:
> (0) did attempt to address every point raised by reviewers (to the 
> extent I thought I understood them);
> (1) didn't take suggestions apparently due to reviewer lacking UAS 
> context, instead added missing context;

Normal.  If the reviewer suggests something that indicates that enough 
context is not provided, provide the context.  Or references to context.

> documents (but will if the WG prefers);

Agree.  I actually was ready to change the definitions in uas-rid and 
operator-privacy and wow, no aviation definitions.  And I thought about 
it and agree that ALL aviation definitions SHOULD be in reqs and/or 
arch.  Of course if new ones come up after those are published, new 
drafts will have to deal with it.

> review question from Michael R.: Should GEN-1 be exploded into 
> multiple numbered requirements?

Sounds nice but the PHYs selected, for the most part do not allow for 
this, and we cannot say, "tough, you have to only use PHYs that can 
support this, or operate in such a way this works."

So no.

But Adam's auth DOES provide for this.  So maybe to have it and then 
show what little can support it.
> (b) defense against replay attacks

Only Adam's auth provides this and we did consider it in the design...

> (c) defense against spoofing

Same.

> (d) connected to a sender public key (related to GEN-3)

This is nice, but it SHOULD be a solution for other requirements. IMHO, 
we do not req public key.  We show how reqs are met with public key tech.

So, no.

> (e) Observer w/o Internet at time of observation

This may be worthwhile.  It is in the FAA ConOps.  I think.  And we do 
design for it.

> requirements text, focusing on the previously debated PRIV-2 and 
> PRIV-3 plus the newly added (based on reviewers' comments) PRIV-4 and 
> PRIV-5.

Looks like my operator-privacy again is not getting on the agenda for 
PRIV-2.  :)

I will look at 4 & 5, then comment.

> Thanks. Good night!
>
>
> On Tue, Aug 25, 2020 at 11:06 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     [email-masked] <mailto:[email-masked]>

-- 
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: Robert Moskowitz <[email-masked]>
Date: Wed, 26 Aug 2020 09:02:46 -0400

Only comment, after a look at the diffs is that PRIV-3 should come after 
the new 4 & 5.  DRIP directly can provide for 4&5...

On 8/26/20 7:55 AM, Robert Moskowitz wrote:
>> (3) didn't remove definitions of terms likely to be used in other 
>> DRIP documents (but will if the WG prefers);
>
> operator-privacy and wow, no aviation definitions.  And I thought 
> about it and agree that ALL aviation definitions SHOULD be in reqs 
> and/or arch.  Of course if new ones come up after those are published, 
> new drafts will have to deal with it.
>
> This is nice, but it SHOULD be a solution for other requirements. 
> IMHO, we do not req public key.  We show how reqs are met with public 
> key tech.
>
> So, no.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Aug 2020 10:33:05 -0400

> operator-privacy and wow, no aviation definitions.  And I thought about it
    > and agree that ALL aviation definitions SHOULD be in reqs and/or arch.  Of
    > course if new ones come up after those are published, new drafts will have to
    > deal with it.

Would you consider in other documents, putting something like <a> after
the Aviation origin TLAs?
I think that reviewers are going to have a lot of difficulty with them.

    > Sounds nice but the PHYs selected, for the most part do not allow for this,
    > and we cannot say, "tough, you have to only use PHYs that can support this,
    > or operate in such a way this works."

    > So no.

I don't understand.  Are you saying that PHYs can not satisfy GEN-1?
I'm asking that requirements here be more clearly labelled so that the can
later be referred to.

   GEN-1   Provable Ownership: DRIP MUST enable verification that the
           UAS ID asserted in the Basic ID message is that of the actual
           current sender of the message (i.e. the message is not a
           replay attack or other spoof, authenticating e.g. by
           verifying an asymmetric cryptographic signature using a
           sender provided public key from which the asserted ID can be
           at least partially derived), even on an observer device
           lacking Internet connectivity at the time of observation.

What I think I was complaining about is the 5-line (), with commas.

   GEN-1A  Provable Ownership: DRIP MUST enable verification that the
           UAS ID asserted in the Basic ID message is that of the actual
           current sender of the message.

   GEN-1B  The Provable Onwership MUST be resistant to replay attacks,
           both malicious attempts, and inadvertant repeats due to radio
           waves taking multiple paths.

   GEN-1C  It MUST be possible for an observer device
           lacking Internet connectivity at the time of observation to
           verify the UAS ID asserted.

(I think 1C is pretty difficult)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 26 Aug 2020 12:40:30 -0400

Not really attempting 1C as written: attempting to verify that messages
really come from the entity from which they claim to originate; attempting
to verify that entity is really in the registry in which it claims to be;
then inferring whatever I wish from which registry that is.

In last night's -reqs-04, I clarified that essentially all the terminology
comes from the UAS user community, and marked those few terms we have
invented in DRIP.

On Wed, Aug 26, 2020 at 10:33 AM Michael Richardson <[email-masked]>
wrote:

> about it
>     > and agree that ALL aviation definitions SHOULD be in reqs and/or
> arch..  Of