Subject: [Tm-rid] Comments on transparency in DRIP meeting

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Mar 2020 22:55:28 +0100

To restate/summarize:

IMHO the requiremnts should include things like:
a) There needs to be the ability for an authenticated cleartext information block from the drone.
   IMHO it would be good to make this requirement this string, because
   it would mean that it does not depend on a third-party to decode the
   information. MAYBE third party to authenticate.
-> There needs to be the ability for authenticated, need-to-know information about the drone
   IMHO, this could be information that could come directly from the
   drone or third party.

Wrt. requirements/architecture:
IMHO it would be good to document what stewart said in the queue, e.g.:
Identifiers being public knowledge, whereas information about operator
and/or other metadata may be handled differntly (Stewart would know
better).

Overall, i think it would be very good for the public discourse about
drones if there was even more transparency about them than we may have
had with planes. If drones become as ubiquitous as cars, the community
which they invade would certainly like to know more than identifiers
that might be hard to track. I do recognize/distinguish Waze/Google cars on my
streets in mountain view, i don't think i would be able to distinguish
photography taking drones from others. I may be able to recognize the
heavily loaded amazon drone, but if there are competing delivery
drones, and one is louder or otherwise more obnoxious, would i be
able to point to the operator using those bad drones ?

Etc... pp..

Cheers
    Toerless

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 25 Mar 2020 18:50:15 -0400

> and/or other metadata may be handled differntly (Stewart would know

We have vocalized these points.  Now we have to get them down in bits 
and bytes.

I dived into a possible implementation, but we do need better arch/req 
stated.

> able to point to the operator using those bad drones ?

If you look at some of the comments to the FAA NPRM, you get the drift 
that many that are vocal don't want ANY regulations; they just want 
their right to fly.  there are thousands of comments about FAA Stay 
Away, and very few constructive comments.

Of course, I made my comment which I feel was constructive.  :)

How to get meaningful public discourse is always challenging.

Bob

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 30 Mar 2020 02:08:06 -0400

Thanks Toerless!

I guess there are 3 distinct issues here:

(1) What do we want the regulations to be? We (individually, or as the
IETF) don't get to make the regulations, but we (individually) can present
our opinions, directly to the regulators, and in public fora.

(2) What capabilities do we want to offer to the regulators, potentially
including some that they did not know were feasible (and so specified
things we like less)?

(3) How might we provide those capabilities with the most interoperable,
reliable, performant, etc. techniques?

The EU has already said thou shalt Broadcast (in clear plaintext ) thy
static manufacturer assigned serial number and some other info.

The US has already said that it plans to require in all cases Network
transmission (preferably encrypted) of either the serial number or a
single-use session ID and some other info to servers that will respond to
public queries on some information and Government queries on all
information, and in many cases also Broadcast transmission (in clear
plaintext) of exactly the same information.

Still more information will neither be Broadcast nor Network transmitted,
but added in advance to registries, where lookups are to be access
controlled.

Probably the most sensitive item to be transmitted in real time is the
location of the pilot and Ground Control Station. MY OPINION: While so far
there have not been mobs with baseball bats, so far nobody has used a drone
to spray a biological or chemical agent over a full stadium; once someone
does that, every other UAS pilot is a potential target of an angry mob.
Yes, the location of the driver of a car is known to anyone observing the
car, but he is relatively safe in (and able to flee using) the car;
likewise the pilot of a manned aircraft; remotely piloted vehicles are
different in this respect. If someone is observed misusing a drone, the
idea is that the identifier, having been sent in the clear, can be reported
to law enforcement, who will be able to look up the miscreant in the
registry and take appropriate action, rather than have the observer trigger
vigilante action.

My primary focus thus far has been on integrating & documenting technical
means to authenticate whatever information is sent, with a secondary focus
on enabling (not requiring, as that is up to the regulators) protection of
privacy of whatever information is deemed appropriate to be so protected.

On Wed, Mar 25, 2020 at 5:55 PM Toerless Eckert <[email-masked]> wrote:

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

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 30 Mar 2020 10:36:19 +0200

> static manufacturer assigned serial number and some other info.
It has not actually said that, afaiu. Regulations still under
development but heavily contested.

best regards,

Amelia

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 30 Mar 2020 08:16:59 -0400

On 3/30/20 2:08 AM, Card, Stu wrote:
> IETF) don't get to make the regulations, but we (individually) can 
> present our opinions, directly to the regulators, and in public fora.
>
> (2) What capabilities do we want to offer to the regulators, 
> potentially including some that they did not know were feasible (and 
> so specified things we like less)?

An example of this is the size of EdDSA public keys and the size of the 
signature.  The fact that I was able to come up with a sig in ~84 bytes 
and a cert ~200bytes was a big surprise to many that I met, but 
something those of us in IETF were already well aware of.

> (3) How might we provide those capabilities with the most 
> interoperable, reliable, performant, etc. techniques?
>
> single-use session ID and some other info to servers that will respond 
> to public queries on some information and Government queries on all 
> Still more information will neither be Broadcast nor Network 
> transmitted, but added in advance to registries, where lookups are to 
> be access controlled.
>
> location of the pilot and Ground Control Station.

And ASTM (System Message) does this in the clear!  It should be an 
opaque (encrypted) object that takes the UTM to interpret.

This is something else I need to write a draft for.  I want to see if I 
can do it with ECIES rather than a symmetric key from an Operator/UTM 
secure session.

But it can't be the operator's long-lived ID key, as that is just as bad 
as in the clear.  It would have to be some mission ID with the UTM.

Hmm.  Stay tuned.  I think I got it.  Any co-authors out there?

> MY OPINION: While so far there have not been mobs with baseball bats, 
> so far nobody has used a drone to spray a biological or chemical agent 
> over a full stadium; once someone does that, every other UAS pilot is 
> a potential target of an angry mob. Yes, the location of the driver of 
> a car is known to anyone observing the car, but he is relatively safe 
> in (and able to flee using) the car; likewise the pilot of a manned 
> aircraft; remotely piloted vehicles are different in this respect. If 
> someone is observed misusing a drone, the idea is that the identifier, 
> having been sent in the clear, can be reported to law enforcement, who 
> will be able to look up the miscreant in the registry and take 
> appropriate action, rather than have the observer trigger vigilante 
> action.
>
> My primary focus thus far has been on integrating & documenting 
> technical means to authenticate whatever information is sent, with a 
> secondary focus on enabling (not requiring, as that is up to the 
> regulators) protection of privacy of whatever information is deemed 
> appropriate to be so protected.
>
>
> On Wed, Mar 25, 2020 at 5:55 PM Toerless Eckert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     To restate/summarize:
>
>     [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