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

[Adam Wiethuechter <[e-mail]>]

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 <[e-mail]> on behalf of Robert Moskowitz <[e-mail]>
Sent: Wednesday, October 20, 2021 4:19 PM
To: [e-mail] <[e-mail]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-rid-11.txt

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.



On 10/20/21 4:13 PM, [e-mail] 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)
>          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/
>
>

--
Tm-rid mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tm-rid