Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-drip-operator-privacy-00.txt

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Apr 2020 08:53:11 -0400

This is a new draft for the wg to consider.

The ASTM System Message contains (currently) 8 bytes worth of Operator 
PII:  Where is the Operator.

In Broadcast RID, this is sent in the clear to all observers.  Not so good.

This draft encrypts those fields using an hybrid ECIES approach. Only 
the Operator's USS can decrypt the content and make it available to 
authorized entities.

Two challenges in this draft (that's all ;) ):

What cipher to use that can encrypt 64 bits in place.  Speck is used, 
with all of its negative reviews.  This morning I was pointed to a 
survey of ciphers that may offer an alternative cipher.

Who does this draft work with cs-rid?  If the SDSP in cs-rid is not the 
USS, it has to 'ask' the USS for help, so the backend gets complex, but 
that is out-of-scope here.

Finally issue.  ASTM F38 is virtually meeting next week.  I will miss 
the F38.02 session wednesday, as that is Passover.  Stu, Adam, and Ray 
will cover.  One topic will be to add potentially 4 bytes to this 
message to add Operator Barometric Altitude per the FAA and EU request.  
So now I have to encrypt 96 bits!  Of course once we are opening up the 
box, if I can get them to add a 2 byte counter, I can use AES-CTR (this 
point is in the draft).

Anyway, right now it is a short draft and really expects the reader to 
know about the ASTM messages and other DRIP work.

Enjoy, all!

Bob

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-moskowitz-drip-operator-privacy-00.txt
Date: 	Wed, 01 Apr 2020 05:25:21 -0700
From: 	[email-masked]
To: 	Stuart Card <[email-masked]>, Stuart W. Card 
<[email-masked]>, Robert Moskowitz 
<[email-masked]>, Adam Wiethuechter 
<[email-masked]>

A new version of I-D, draft-moskowitz-drip-operator-privacy-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-operator-privacy
Revision: 00
Title: Operator Privacy for RemoteID Messages
Document date: 2020-03-31
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/internet-drafts/draft-moskowitz-drip-operator-privacy-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/
Htmlized: 
https://tools.ietf.org/html/draft-moskowitz-drip-operator-privacy-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-operator-privacy

Abstract:
This document describes a method of providing privacy for Operator
information specified in the ASTM UAS Remote ID and Tracking
messages. This is achieved by encrypting, in place, those fields
containing Operator sensitive data using a hybrid ECIES.

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.

The IETF Secretariat

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 1 Apr 2020 15:52:07 -0400

I have gained more information on ciphers I can use here.  I am working 
up the next version where:

1) Recommended cipher will be AES-CFB16 (SP800-38A, sec 6.3) with an IV 
shared between the Operator and USS as outlined in the AES-CTR 
proposal.  This is the cleanest using 'mainstream' crypto.  There is a 
risk in the same IV used for all System Messages for a mission. The 
reason for CFB16 rather, than say CFB8.

2) Speck as currently specified, referencing ISO/29167-22 (need a real 
reference to include in xml)

3) Some other 64 bit cipher TBD.

4) AES-CTR that needs a 2 byte counter added to the message.

Lots of guidance from the cfrg list.

Anyone want to join in the fun?

On 4/1/20 8:53 AM, Robert Moskowitz wrote:
> Who does this draft work with cs-rid?  If the SDSP in cs-rid is not 
> the USS, it has to 'ask' the USS for help, so the backend gets 
> complex, but that is out-of-scope here.
>
> message to add Operator Barometric Altitude per the FAA and EU 
> request.  So now I have to encrypt 96 bits!  Of course once we are 
> opening up the box, if I can get them to add a 2 byte counter, I can 
> use AES-CTR (this point is in the draft).
>

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