[CFRG] Please review draft-ietf-drip-rid

[Robert Moskowitz <[e-mail]>]

Dear cfrg:

I am doing some interesting things with hashing in draft-ietf-drip-rid, 
and I have been instructed to get feedback from CFRGers.

A little background:

The various Civil Aviation Authorities (e.g. FAA) around the world are 
regulating the requirement that Unmanned Aircraft (AKA drones) broadcast 
their Identity (Remote Identification of Unmanned Aircraft) that can 
then be used to learn more about the UA.  ASTM International has 
published a specification, F3411-19, that is the reference document for 
UA manufacturers to meet these regulatory requirements.  Thing is what 
is in F3411-19 is a non-provable claim and open to misuse.

In IETF DRIP, we are defining a Trustable Device Entity Tag (DET) based 
on the Host Identity Tag in RFC 7401 by adding an entity hierarchical 
registry making a Hierarchical Host Identity Tag (HHIT).  This DET will 
be included as an option in the upcoming revision to F3411.  A 
manufacturer does not have to use a provable ID, but here is one way of 
doing it...

Remote IDs are broadcast over:  Bluetooth 4 or 5 or Wifi BEACONs or 
NAN.  The messages for WiFi and BT 5 are 250 bytes, but BT4 limits it to 
25 bytes!  The actual ID in F3411 is limited to 20 bytes.  In 
draft-ietf-drip-rid we define a Trustable Remote ID of 16 bytes which is 
a valid, non-routable IPv6 address.  In draft-ietf-drip-auth we define 
how to authenticate ownership of our DET within the 250 byte message 
limit or 9 chained BT4 messages (chaining of BT4 messages supported in 
F3411).

Here I am only asking for a review of draft-ietf-drip-rid.  We will get 
to draft-ietf-drip-auth later!  But looking at it will help fill in some 
whys.

Now on to the actual review request:

DETs are constructed by hashing a public ED25519 Host Identity with 
other information (see sec 3) using cSHAKE128.  A python script to 
create HHITs is available (see Informative Ref hhit-gen).

In most uses the actual hash size is 64 bytes.  Per Appendix C, the 
probablity of a collision is .01% in a population of 66M and 1% in a 
population of 663M.  We have a script that we will be making available 
that we ran to 1M HHITs and did not produce a collision. This script 
will be posted on github with its next version (right now it is 3 
separate scripts).

First level review is how I am creating this Cyptographically Generated 
Address.  Second is my math correct on the probablity of collisions.

It is expected that each DET registrar will protect against the 
registration of duplicate DETs (draft draft-wiethuechter-drip-registries 
is really drafty) so only one UA will be able to register a specific 
public ED25519 Host Identity and DET with that DET registrar.

Note that a UA may register a new DET for each "operation" (e.g. for 
each FEDEx delivery flight or 'only' one per day per UA), so a DET 
registrar could run through a LOT of DETs and could easily be rejecting 
a registration attempt as a duplicate.

The next concern is that of pre-image attacks against the hashing. I 
have not found any literature on this.  What is the risk?  How 'easy' is 
it to do with a hash of 64 bits.  I have text on this in the Security 
Considerations section.  This this adequate?  Is more information 
available that I can incude here?

I do not talk at all about the risk of multiple private keys for a 
public ED25519 key.  Do I need to include this?  I ASSuME that given the 
signature from draft-ietf-drip-auth and the public key, the receiver can 
trust the sender.

So that is pretty much it on request of CFRG to review 
draft-ietf-drip-rid.  DET privacy stuff (sec 8) I will take to SAAG.

I am looking forward to your responses.  I will be back to you on 
drip-auth when it is a little closer to done.  Though feel free to 
advise on it to.

Thank you

Robert Moskowitz