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

[Robert Moskowitz <[e-mail]>]

On 10/22/21 11:10 PM, Adam Wiethuechter wrote:
> 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.
>
Fixed.

> Section 2.2 -- is this needed here if its in -arch/-registries? It is 
> 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.

> 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
>
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.
>
> A lot of this should become clearer as -registries finally gets 
> fleshed out.
>
> Section 9 -- already present in F3411?

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

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.

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

Don't fry your brain.  We need it.

>
> --------
> 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/ 
> <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 
> <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 
> <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/ 
> <ftp://ftp.ietf.org/internet-drafts/>
> >
> >
>
> -- 
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid 
> <https://www.ietf.org/mailman/listinfo/tm-rid>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

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