Subject: Re: [Drip] DET PRrivacy

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Sep 2021 16:59:30 -0400

I have make an attempt to rewrite my DET Privacy.  I want this in want I 
present to SAAG for review as there live the privacy wonks. CFRG, not so 
concerned about.  :)

8.  DET Privacy

    There is no expectation of privacy for DETs.  DETs are broadcast in
    the clear over the open air via Bluetooth and WiFi.  They will be
    collected and collated with other public information about the UAS.
    This will include DET registration information and location and times
    of operations for a DET.  A DET can be for the life of a UA if there
    is no concern about DET/UA activity harvesting.

    Further, the MAC address of the wireless interface used for Remote ID
    broadcasts are a target for UA operation aggregation that may not be
    mitigated through address randomization.  For Bluetooth 4 Remote ID
    messaging, the MAC address is used by observers to link the Basic
    Message that contains the RID with other Remote ID messages, thus
    MUST be constant for a UA operation.  This message linkage use of MAC
    addresses may not be needed with the Bluetooth 5 or WiFi PHYs. These
    PHYs provide for a larger message payload and can use the Message
    Pack (Msg Type 0xF) and the Authentication Message to transmit the
    RID with other Remote ID messages.  However it is not manditory to
    send the RID in a Message Pack or Authentication Message, so
    allowance for using the MAC address for UA message linking MUST be
    maintained.  That is, the MAC address should be stable for at least a
    UA operation.

    Finally, it is not adequate to simply change the DET and MAC for a UA
    per operation to defeat historically tracking a UA's activity.

    Any changes to the UA MAC may have impacts to C2 setup and use. A
    constant GCS MAC may well defeat any privacy gains in UA MAC and RID
    changes.  UA/GCS binding is complicated with changing MAC addresses;
    historically UAS design assumed these to be "forever" and made setup
    a one-time process.  Additionally, if IP is used for C2, a changing
    MAC may mean a changing IP address to further impact the UAS
    bindings.  Finally an encryption wrapper's identifier (such as ESP
    [RFC4303] SPI) would need to change per operation to insure operation
    tracking separation.

    Creating and maintaining UAS operational privacy is a multifaceted
    problem.  Many communication pieces need to be considered to truly
    create a separation between UA operations.  Simply changing the UAS
    RID only starts the changes that need to be implemented.

On 8/10/21 4:32 PM, Robert Moskowitz wrote:
> I have been working on text for DET Privacy.  This is NOT an easily 
> achieved goal.  Please review and comment here about the proposed text 
> for ver -10:
>
> 8.  DET Privacy
>
>    DETs are broadcast in the clear and will be collected and collated
>    with other public information about the UAS.  This will include
>    location and times of operations for a DET.  A DET can be for the
>    life of a UA if there is no concern about UA activity harvesting.  It
>    is not adequate to simply change the DET for a UA per operation to
>    defeat historically tracking a UA's activity.
>
>    The UAS Remote ID (of all types) only appear in the Remote ID Basic
>    Message; the wireless MAC address is used to aggregate Remote ID
>    messages to a UA for meeting the FAA rules [FAA_RID] (as well as
>    rules from other CAAs).  As such, the MAC address, like the UAS RID,
>    SHOULD be unchanging for the duration of an operation.  As the DET is
>    changed, so too SHOULD the MAC address change to break any historical
>    tracking at the Remote ID message level.
>
>    However, any changes to the UA MAC may have impacts to C2 setup and
>    use.  A constant GCS MAC may well defeat any privacy gains in UA MAC
>    and RID changes.  Further, UA/GCS binding is complicated with
>    changing MAC addresses; historically UAS design assumed these to be
>    "forever" and made setup a one-time process.  Additionally, if IP is
>    used for C2, a changing MAC may mean a changing IP address to further
>    impact the UAS bindings.  Finally an encryption wrapper's (such as
>    ESP [RFC4303]) identifier would need to change per operation to
>    insure operation tracking separation.
>
>    Creating and maintaining UAS operational privacy is a multifaceted
>    problem.  Many communication pieces need to be considered to truly
>    create a separation between US operations.  Simply changing the UAS
>    RID only starts the changes that need to be implemented.
>
>
>

-- 
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: <[email-masked]>
Date: Mon, 6 Sep 2021 11:52:55 +0000

Hi Bob,

Thank you for drafting this text. Please find below some comments:

·         As we have a similar discussion in the req I-D, I wonder whether you can add a pointer to the privacy section in the req I-D.

·         I wonder whether you really need to keep “There is no expectation of privacy for DETs” given that the point of this section is to discuss/identify DET privacy-related considerations at the first place.

·         I would avoid using the normative language for the MAC address persistence/stability. Calling out the implications when such stability is not provided is sufficient, IMO.

Other than that, this looks good. Thanks.

Cheers,
Med

De : Tm-rid [mailto:[email-masked]] De la part de Robert Moskowitz
Envoyé : jeudi 2 septembre 2021 23:00
À : [email-masked]
Objet : Re: [Drip] DET PRrivacy

I have make an attempt to rewrite my DET Privacy.  I want this in want I present to SAAG for review as there live the privacy wonks.  CFRG, not so concerned about.  :)

8.  DET Privacy

On 8/10/21 4:32 PM, Robert Moskowitz wrote:
I have been working on text for DET Privacy.  This is NOT an easily achieved goal.  Please review and comment here about the proposed text for ver -10:

8.  DET Privacy

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [email-masked]<mailto:[email-masked]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit

_________________________________________________________________________________________________________________________

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.