Subject: [Drip] I-D Action: draft-ietf-drip-rid-11.txt

From: [email-masked]
Date: Wed, 20 Oct 2021 13:13:50 -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           : DRIP Entity Tag (DET) for Unmanned Aircraft System Remote Identification (UAS RID)
        Authors         : Robert Moskowitz
                          Stuart W. Card
                          Adam Wiethuechter
                          Andrei Gurtov
	Filename        : draft-ietf-drip-rid-11.txt
	Pages           : 29
	Date            : 2021-10-20

Abstract:
   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses and thereby a trustable
   identifier for use as the Unmanned Aircraft System Remote
   Identification and tracking (UAS RID).  Within the context of RID,
   HHITs will be called DRIP Entity Tags (DET).  HHITs self-attest to
   the included explicit hierarchy that provides Registrar discovery for
   3rd-party identifier attestation.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-rid-11.html

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

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

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 20 Oct 2021 16:19:01 -0400

Changes in sec 4.2 and 11.  Please review.

Adam and I are discussing sec 5, as he actually has done some 
implementation demos and I may make adjusts along what he has done.

Also Adam and I need to work out App B and drip-auth.

So there may be yet an update before the cutoff.  Of course comments are 
welcome and I will make adjusts as needed.

---

From: <[email-masked]>
Date: Thu, 21 Oct 2021 06:40:44 +0000

Hi Robert, 

Thank you for addressing the comment from the cfrg, particularly this one: https://mailarchive.ietf.org/arch/msg/cfrg/tAJJq60W6TlUv7_pde5cw5TDTCU/ 
BTW, please check the 2nd line of the third paragraph of the new text about pre-image attack as I'm not sure to parse it. 

Also, it could be great if you can motivate the change in the normative language in Section 4.2. Thank you.

All: please review and share your comments. This is highly appreciated.

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid <[email-masked]> De la part de Robert Moskowitz
> Envoyé : mercredi 20 octobre 2021 22:19
> À : [email-masked]
> Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt
> 
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid

_________________________________________________________________________________________________________________________

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: Robert Moskowitz <[email-masked]>
Date: Thu, 21 Oct 2021 08:33:28 -0400

> BTW, please check the 2nd line of the third paragraph of the new text about pre-image attack as I'm not sure to parse it.

Is the following an improvement?

Now it should be noted that the 2^64 attempts is for stealing a
     *specific* HHIT.  Consider a scenario of a street photography
     company with 1,024 UAs (each with its own HHIT); you'd
     be happy stealing any one of them.  Then rather than needing to 
satisfy a
     64-bit condition on the cSHAKE128 output, you need only satisfy
     what is equivalent to a 54-bit condition (since you have 2^10 more
     opportunities for success).

-- 
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: Thu, 21 Oct 2021 09:09:19 -0400

> Also, it could be great if you can motivate the change in the normative language in Section 4.2. Thank you.

I believe this is about the MUSTs in:

     The low-order 68 bits (HIT Suite ID | ORCHID hash) of the HHIT
     SHALL be left-padded with 2 bits of ZERO.  This 70 bit number will
     be encoded into 14 characters using the digit/letters above. The
     manufacturer MUST use a Length Code of F (15).  The first character
     after the Length Code MUST be 'Z', followed by the 14 characters of
     the encoded HIT Suite ID and ORCHID hash.

At first I was allowing either for a Length Code of E or F and if F then 
choose what you want for the first character of the MFR SN field.

Then I considered the other side:  the observer that will be parsing 
this CTA SN.

How to at least hint to the receiver that the CTA SN MAY be an encoded 
HHIT and either watch for a Authentication Message to directly prove it 
or look up (in some yet to be defined service) the MFR CODE to see if it 
points to a HHIT PREFIX|HID.

So I realized I needed to strongly restrict the encoding rules to 
facilitate the receiver processing.  That 'FZ' provides the hint to the 
receiver that this CTA SN MAY be an encoded HHIT.

Of course we can use ANY of the 34 allowed characters, I chose 'Z' with 
no explanation.

Note that at first I wrote it with SHOULD, but that still leaves it up 
to the sender with resultant impact on the receiver.  So I used MUST.

---

From: <[email-masked]>
Date: Thu, 21 Oct 2021 13:25:40 +0000

Re-,

That’s better. Thank you.

As we are in that section, there is also this nit:

   Thus, although the PROBABILITY of a collision or pre-image attack is
   low Section 11.2<https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-11.txt#section-11.2> in a collection of 1,024 HHITs out of a total
   ^^^^^^^^^^^^^^^^^^^^

Cheers,
Med

De : Robert Moskowitz <[email-masked]>
Envoyé : jeudi 21 octobre 2021 14:33
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt

On 10/21/21 2:40 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Robert,

    be happy stealing any one of them.  Then rather than needing to satisfy a

Cheers,

Med

-----Message d'origine-----

De : Tm-rid <[email-masked]><mailto:[email-masked]> De la part de Robert Moskowitz

À : [email-masked]<mailto:[email-masked]>

On 10/20/21 4:13 PM, [email-masked]<mailto:[email-masked]> wrote:

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           : DRIP Entity Tag (DET) for Unmanned Aircraft

System Remote Identification (UAS RID)

                           Stuart W. Card

                           Adam Wiethuechter

                           Andrei Gurtov

    Pages           : 29

    Date            : 2021-10-20

Abstract:

    the included explicit hierarchy that provides Registrar discovery

for

--

Tm-rid mailing list

[email-masked]<mailto:[email-masked]>

Thank you.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 21 Oct 2021 09:31:17 -0400

On 10/21/21 9:25 AM, [email-masked] wrote:
> Standard
>    low Section 11.2 
> <https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-11.txt#section-11.2>in 
> a collection of 1,024 HHITs out of a total
>
>    ^^^^^^^^^^^^^^^^^^^^
>

Oops...

    Thus, although the PROBABILITY of a collision or pre-image attack is
    low in a collection of 1,024 HHITs out of a total population of 2^64,
    per Section 11.2, it is computationally and economically feasible.
    Thus the HHIT registration and HHIT/HI registration validation is
    STRONGLY recommended.

> Cheers,
>
> Med
>
> *De :* Robert Moskowitz <[email-masked]>
> *Envoyé :* jeudi 21 octobre 2021 14:33
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 
> [email-masked]
> *Objet :* Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt
>
> On 10/21/21 2:40 AM, [email-masked] 
> <mailto:[email-masked]> wrote:
>
>     Hi Robert,
>
>     Thank you for addressing the comment from the cfrg, particularly this one:https://mailarchive.ietf.org/arch/msg/cfrg/tAJJq60W6TlUv7_pde5cw5TDTCU/  <https://mailarchive.ietf.org/arch/msg/cfrg/tAJJq60W6TlUv7_pde5cw5TDTCU/>  
>
>         De : Tm-rid<[email-masked]>  <mailto:[email-masked]>  De la part de Robert Moskowitz
>
>         À :[email-masked]  <mailto:[email-masked]>
>
>         On 10/20/21 4:13 PM,[email-masked]  <mailto:[email-masked]>  wrote:
>
>             https://datatracker.ietf.org/doc/draft-ietf-drip-rid/  <https://datatracker.ietf.org/doc/draft-ietf-drip-rid/>
>
>             https://www.ietf.org/archive/id/draft-ietf-drip-rid-11.html  <https://www.ietf.org/archive/id/draft-ietf-drip-rid-11.html>
>
>             https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-rid-11  <https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-rid-11>
>
>             ftp://ftp.ietf.org/internet-drafts/  <ftp://ftp.ietf.org/internet-drafts/>
>
>         --
>
>         Tm-rid mailing list
>
>         [email-masked]  <mailto:[email-masked]>
>
>         https://www.ietf.org/mailman/listinfo/tm-rid  <https://www.ietf.org/mailman/listinfo/tm-rid>
>
> E: [email-masked] <mailto:[email-masked]>
>

---

From: Adam Wiethuechter <[email-masked]>
Date: Sat, 23 Oct 2021 03:10:30 +0000

Bob,

Here is my list of changes for you and some discussion points.

/s/HITs are statistically unique through the cryptographic hash feature of second-preimage resistance./
HHITs are statistically unique through the cryptographic hash feature of second-preimage resistance.

Section 2.2 -- is this needed here if its in -arch/-registries? It is also outdated compared to -arch.

Section 4 -- You should add TYPE-4 and clarify that a TYPE-4, subtype 1 is a DRIP Entity Tag (its already in F3411).

Section 4.2 -- /s/Basic Message/Basic ID Message

Section 4.6 -- See Appendix B discussions below

Section 5

Change the DET reverse lookup to:

a3ad1952ad0a69e.5.20.10.det.remoteid.aero

I do not understand why we are included the prefix in this when its static for the DET format (2001:30/28) and why we were breaking the HHIT up by its hextets instead of its fields. I have been using the following form for DET FQDNs:

<hash_hex>.<ogaid_hex>.<hda_int>.<raa_int>.det.remoteid.aero

I question if the HDA and RAA value should stay in hex form. I have been using the full form (included the padding 0s) - your example uses a condensed version. Be warned that DNS that is a different FQDN, meaning we would need records for them.

In my implementation work I have found that DNS is case-sensitive (something I did not know!). We need to decided if its upper or lower case (for both DETs and Serial Numbers). This is probably a -registries thing rather than this draft.

A lot of this should become clearer as -registries finally gets fleshed out.

Section 9 -- already present in F3411?

Section 11.1 -- /s/ASTM Basic Message/ASTM Basic ID Message

Appendix B -- should just be the SelfAttestation (-auth-formats B.1)

Appendix B.1

This is just a BroadcastAttestation (-auth-formats B.6) but not signed by the UA dynamically. See -auth-formats security considerations on replay attacks for the reason myself and Stu thought of a few months ago.

You mentioned in a review of my -auth-formats that you think a 2-byte offset instead of a full 4-byte expiration timestamp would be better.

First even if we switch to a 2-byte offset format for expiration time (on ALL Attestations/Certificates) we will still blow the Authentication Data limit of 200. By 4-bytes in fact.

Second, two bytes can only offset by ~45 days. This is arguably not enough time for longer lasting attestations (such as the BroadcastAttestation).

We either have an expiration timestamp (and do not dynamically sign the BroadcastAttestation) or we don't (and the BroadcastAttestation is a static item being broadcast by the UA) - the size limit gives us those two options.

We _could_ do something like the psuedo-TCP header for this "special" format (potentially requiring another SAM Type allocation). We dynamically sign the BroadcastAttestation (136-bytes) and append the signature, using the ASTM Authentication Message timestamp as part of the signing operation. This will require F3411 implementations allowing the higher layers to set/get the timestamp of the Authentication Message before it is sent. For a highly embedded design where the F3411 implementation is buried deep and interconnect with the Bluetooth/Wi-Fi stack this could be impossible - an implementation may not even allow you to see the timestamp as its part of the F3411 framing, only giving the application an API to set/get data.

Another option, one I do NOT like, is to have another Attestation format defined that looks the same as the BroadcastAttestation but missing a timestamp and special rules about how it is used. To me, that sounds like a recipe for confusion no matter what we write in the documents.

Overall, I think this is all avoided by the following: In -auth-formats I specify that the BroadcastAttesation (carried by DRIP Link) is not enough. You MUST also send dynamically signed data, using either DRIP Wrapper or DRIP Manifest. We can extend this to also have the option to send AuthType 0x1 (UA SelfAttestation) with a freshly generated SelfAttestation of the aircraft.

On a related note:

Stu brought up in a discussion today with me that a protentional vulnerability is that someone registers you in a valid registry by stealing your HI, forging a new HHIT with it and registering it somewhere else. '

An Observer would obtain the BroadcastAttestation, check its signature (made by the registry) and it would validate. This Observer would then start to make assumptions based on registry metadata and could potentially go after someone for being in a registry "they don't like".

There are a few problems with this:

1) is that the registry should be validating any SelfAttestations being sent in. If the registry is flawed (or in on the scheme) this could get past such a check.
2) an Observer with just the BroadcastAttestation would think everything is fine, but as soon as other signed data appears the signatures would start to fail (all they have is the public HI, not the private key). If the bad actor just doesn't send dynamic data, it is already suspicious as -auth-formats has that they MUST do so.

Mitigating 1) is by having a vetting process before being added to the hierarchy and periodically checking to confirm conformance.
Mitigating 2) is self-discipline of the receiver device code. A rabbit hole we probably shouldn't go down.

We need to discuss this specific issue in more detail and determine if such a corner case should be worried about.

My brain is now fried -- I will use what remaining power I have to work on -registries some more.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Tm-rid <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Sent: Wednesday, October 20, 2021 4:19 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 25 Oct 2021 17:41:10 -0400

> of second-preimage resistance.
Fixed.

> also outdated compared to -arch.

It was added at a time neither had these notations.  I will add an 
editor's note that this will be reviewed against drip-arch and drip-auth 
and a consistent source will be established.  Though I wonder if it 
should be drip-auth since it is definitive.  But | is always in Notations...

> Section 4 -- You should add TYPE-4 and clarify that a TYPE-4, subtype 
> 1 is a DRIP Entity Tag (its already in F3411).

So far, I have tried to stay consistent with what is published 
externally versus what is expected.

To make this change at this time I SHOULD add text that this reflects 
the current balloting process in ASTM and is likely to be the format of 
the final published version.

I have dealt with similar challenges between IETF and IEEE.  At least 
with these two, MOST stuff is public.  We had a issue, at first, with 
IEEE 802.1X, until the drafts were made available to EAP.

> Section 4.2 -- /s/Basic Message/Basic ID Message

There were a LOT of these to fix.  Thanks.

> I do not understand why we are included the prefix in this when its 
> static for the DET format (2001:30/28) and why we were breaking the 
> HHIT up by its hextets instead of its fields. I have been using the 
> following form for DET FQDNs:
>
Because we don't know if 2001:30/28 will be the only prefix for DETs.  
So include it.

And you are proposing one in .aero which can be implemented now in testing.

I am proposing a standards one under .arpa

I will put them both in for now.

> I question if the HDA and RAA value should stay in hex form. I have 
> been using the full form (included the padding 0s) - your example uses 
> a condensed version. Be warned that DNS that is a different FQDN, 
> meaning we would need records for them.
>
> In my implementation work I have found that DNS is case-sensitive 
> (something I did not know!). We need to decided if its upper or lower 
> case (for both DETs and Serial Numbers). This is probably a 
> -registries thing rather than this draft.
>

No. It is proposed, differently as you noted and in balloting.  Not in 
F3411 until balloting passes.  And then there is technical editing, 
which probably will NOT change the format, but conceivably change the 
assigned values.

I will see if I can rework this to reflect what SHOULD be coming in the 
next version.  in this section.

> Section 11.1 -- /s/ASTM Basic Message/ASTM Basic ID Message

And all the other places I had it wrong!

> Appendix B -- should just be the SelfAttestation (-auth-formats B.1)

You have a basically a signing and validity timestamp.  I would 
recommend you change your Trust Timestamp in drip-auth to something like 
Valid Until Timestamp or simply Validity Timestamp.

Also you include the HI, I do not.  Including the HI adds to the number 
of BT4 frames needed for the Authentication Message.  Like 3 frames.  If 
the UA is hanging around, OK, but if it is moving, is that necessarily a 
good thing?  The DNS lookup is still need. Including the HI 'just' 
allows Sig validation before the lookup.

I am not sold on including the HI here.

>
> Appendix B.1
>
> This is just a BroadcastAttestation (-auth-formats B.6) but not signed 
> by the UA dynamically. See -auth-formats security considerations on 
> replay attacks for the reason myself and Stu thought of a few months ago.

I do not agree with your replay attack considerations.  This will 
require more discussions.  I will leave B.1 in

>
> You mentioned in a review of my -auth-formats that you think a 2-byte 
> offset instead of a full 4-byte expiration timestamp would be better.
>
> First even if we switch to a 2-byte offset format for expiration time 
> (on ALL Attestations/Certificates) we will still blow the 
> Authentication Data limit of 200. By 4-bytes in fact.

I really need to check through all your formats for this.  Not that I 
doubt you, rather how to approach the challenge.

> Second, two bytes can only offset by ~45 days. This is arguably not 
> enough time for longer lasting attestations (such as the 
> BroadcastAttestation).

Depends on the time units in this field.  How fine-grain is needed here?

> We either have an expiration timestamp (and do not dynamically sign 
> the BroadcastAttestation) or we don't (and the BroadcastAttestation is 
> a static item being broadcast by the UA) - the size limit gives us 
> those two options.

B.1 has a 200 byte offline attestation.  One way to "address" this is 
replace the 4 byte Signing Timestamp with 2 offsets, UA signing since 
HDA signing and UA signing validity period.  If the first is in minutes, 
it is good for 45 days; the UA would need a new signed object from the 
HDA.  Or 10 min, then ~15 months.  Some research into what the intervals 
might be, if this approach is used.

But we really need to provide the offline authentication.  It was a part 
of our original justification of how we differ from other approaches.

>
> We _could_ do something like the psuedo-TCP header for this "special" 
> format (potentially requiring another SAM Type allocation). We 
> dynamically sign the BroadcastAttestation (136-bytes) and append the 
> signature, using the ASTM Authentication Message timestamp as part of 
> the signing operation. This will require F3411 implementations 
> allowing the higher layers to set/get the timestamp of the 
> Authentication Message before it is sent. For a highly embedded design 
> where the F3411 implementation is buried deep and interconnect with 
> the Bluetooth/Wi-Fi stack this could be impossible - an implementation 
> may not even allow you to see the timestamp as its part of the F3411 
> framing, only giving the application an API to set/get data.
>
> Another option, one I do NOT like, is to have another Attestation 
> format defined that looks the same as the BroadcastAttestation but 
> missing a timestamp and special rules about how it is used. To me, 
> that sounds like a recipe for confusion no matter what we write in the 
> documents.
>
> Overall, I think this is all avoided by the following:In -auth-formats 
> I specify that the BroadcastAttesation (carried by DRIP Link) is not 
> enough. You MUST also send dynamically signed data, using either DRIP 
> Wrapper or DRIP Manifest. We can extend this to also have the option 
> to send AuthType 0x1 (UA SelfAttestation) with a freshly generated 
> SelfAttestation of the aircraft.
>
> On a related note:
>
> Stu brought up in a discussion today with me that a protentional 
> vulnerability is that someone registers you in a valid registry by 
> stealing your HI, forging a new HHIT with it and registering it 
> somewhere else. '

Game over once your HI private key is stolen.  No need to run down that 
rat hole.

>
> An Observer would obtain the BroadcastAttestation, check its signature 
> (made by the registry) and it would validate. This Observer would then 
> start to make assumptions based on registry metadata and could 
> potentially go after someone for being in a registry "they don't like".
>
> 1) is that the registry should be validating any SelfAttestations 
> being sent in. If the registry is flawed (or in on the scheme) this 
> could get past such a check.
> 2) an Observer with just the BroadcastAttestation would think 
> everything is fine, but as soon as other signed data appears the 
> signatures would start to fail (all they have is the public HI, not 
> the private key). If the bad actor just doesn't send dynamic data, it 
> is already suspicious as -auth-formats has that they MUST do so.
>
> Mitigating 1) is by having a vetting process before being added to the 
> hierarchy and periodically checking to confirm conformance.
> We need to discuss this specific issue in more detail and determine if 
> such a corner case should be worried about.

Mitigating stealing of private keys is totally out of scope.  Don't go 
there.

Well actually there is a whole field of work in Post Compromise 
Security.  MLS deals with that.  We just don't have the bandwidth to do 
those sorts of mitigations.

> work on -registries some more.

Don't fry your brain.  We need it.

> ------------------------------------------------------------------------
> *From:* Tm-rid <[email-masked]> on behalf of Robert Moskowitz 
> <[email-masked]>
> *Sent:* Wednesday, October 20, 2021 4:19 PM
> *To:* [email-masked] <[email-masked]>
> *Subject:* Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt
> >          Title           : DRIP Entity Tag (DET) for Unmanned 
> Aircraft System Remote Identification (UAS RID)
> <https://datatracker.ietf.org/doc/draft-ietf-drip-rid/>
> >
> <https://www.ietf.org/archive/id/draft-ietf-drip-rid-11.html>
> >
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-rid-11>
> >
> >
> <ftp://ftp.ietf.org/internet-drafts/>
> >
> >
>
> -- 
> Tm-rid mailing list
> [email-masked]
> <https://www.ietf.org/mailman/listinfo/tm-rid>
>