Re: [Drip] Intdir last call review of draft-ietf-drip-rid-26

[Robert Moskowitz <[e-mail]>]

Pascal,  Thank you for your review.

On 5/16/22 09:30, Pascal Thubert via Datatracker wrote:
> Reviewer: Pascal Thubert
> Review result: Ready with Nits
>
>
> https://www.ietf.org/id/draft-ietf-drip-rid-26.txt
>
>
>> 1.  Introduction
>>    DRIP Requirements [RFC9153] describe an Unmanned Aircraft System
> Maybe expand DRIP on first use?

Done.

>
>
>>   asserting IPv6 addresses and thereby a trustable identifier for use
>>   as the UAS Remote ID.
> Architecturally speaking, people hate using IPv6 addresses as ID. I foresee
> discussions about address renewal, device replacement (same address?), and
> privacy. We'll see further down the draft but I expect that a dedicated section
> on why this is desirable (and OK) so we do not get endless pushback at IESG.
> https://www.rfc-editor.org/rfc/rfc9153.html#name-identifier does not seem to
> enforce that IP is used. Also, interesting to figure if the model is portable
> to vitually anything, e.g., in IoT.

I have been living this discussion for 25 years.  I have my Kevlar 
suit.  Part of it goes back to discussions I had with Bellovin in '94.  
Addresses are not trustable; it is reachable that gives a small level of 
trust.  Thus the design of HITs.  Lots of opinions since then.  No one 
is 'right', IMHO.


9153 does not enforce it.  It will be later work in other drafts that 
will leverage this.

And it was our intent with HHITs to it be available to other things.  
Just get a different prefix...

>
>
>>   Hierarchical HITs provide self-attestation of the HHIT registry.  A
>>   HHIT can only be in a single registry within a registry system (e.g.,
>>   EPP and DNS).
> Could we imagine a distributed ledger?

Yes, Dr. Gurtov is proposing that as one solution.  It is in an appendix 
in drip-registries as an alternative backend.  Discussion of this does 
not belong in this document.

>
>>    HHITs are statistically unique through the cryptographic hash feature
>>   of second-preimage resistance.
> Good thing that the HHITs are Hierarchical as opposed to only Statistical ;)

The original design for HITs allowed for a 1-level 'hierarchy'.  My 
co-authors at that time did not see a use for it and we removed it, but 
go back to draft-moskowitz-hip-arch-02 and later 
draft-zhang-hip-hierarchical-parameter.  Now there is a use case and I 
believe the design is good.

>
>
>>                            The cryptographically-bound addition
>>   of the hierarchy and a HHIT registration process [drip-registries]
>>   provide complete, global HHIT uniqueness.
>
>
> Coudl issues arise when the global registry is unreachable when the ID is
> formed? Is the HHIT "tentative" till then?

Really can't use it until it is registered.  HHIT owner has no assurance 
that it is unique.  And if the RAA will accept the registration for 
whatever reason.

>
>> 2.  Terms and Definitions
> A forward ref to fig 1 woudl help with all the bit fields.

Please check out changes to HDA, HID, and RAA.  How is this change? Do 
you want this on any other defs?

>
>>   Keccak (KECCAK Message Authentication Code):
> I guess the expansion in () is a CC from the next definition.

Actually from FIPS 202.  Copy and pasted.

>
>> 3.  The Hierarchical Host Identity Tag (HHIT)
>
>>   *  ORCHID hash (96 - prefix length - 8 for HHIT Suite ID, e.g., 64)
>>      See Section 3.5 for more details.
> If P is 28 bits then the hash is 60, which is less than CGA; also this fails to
> align to the usual /64, though whether that's important is debatable. Is there a
> reason to allow P to reach 28 as opposed to 24? Will it be harder to allocate?

Good catch.  Thanks this mistake goes back to 32-bit HID and 4-bit 
HHSI.  Lets see what this should be.

    *  ORCHID hash (92 - prefix length, e.g., 64) See Section 3.5 for
       more details.

We debated byte alignment.  At first we chose to design for it, but the 
request for an 8-bit Suite ID rather than rfc7401's 4/8 design made us 
drop it.  Developers were ok with it.  So no byte alignment.

As for a smaller prefix, it would be GREAT.  But I am not sticking my 
neck out for one!  I have worked out, that in practice, a 28-bit HID 
really should suffice.  But a smaller prefix = a larger hash which...

Do you think you can get IESG to 'vote' that DETs get a /24 or even a 
/20 prefix?  ;)



>
>> 3.1.  HHIT Prefix for RID Purposes
>>   Initially, for DET use, one 28-bit prefix should be assigned out of
>>   the IANA IPv6 Special Purpose Address Block ([RFC6890]).
> Same as above, are we reducing the security properties by having a /28?


Yes.  We rely on the registration process to deal with the 2nd preimage 
attack.  Along with some lookup or authenticated source for the HI (see 
drip-auth and how a 200-byte auth message can provide the HI, signed by 
the HDA's HHIT).

But some will argue that even a 68-bit hash will be attackable in the 
foreseeable future.  At what point do see good enough?

> 3.2.  HHIT Suite IDs
>
>
>>    The following HHIT Suite IDs are defined:
>>
>>        HHIT Suite          Value
>>        RESERVED            0
>>        RSA,DSA/SHA-256     1    [RFC7401]
>>        ECDSA/SHA-384       2    [RFC7401]
>>        ECDSA_LOW/SHA-1     3    [RFC7401]
>>        EdDSA/cSHAKE128     TBD3 (suggested value 5)   (RECOMMENDED)
>>
> I checked the IANA section. It's there though
> - missing references
> - duplicating other efforts for similar registries
>
> e.g., https://www.rfc-editor.org/rfc/rfc8928.html#name-crypto-type-subregistry
> Could you reuse that registry and extend it for the new suite IDs / hash / KMAC?

7401 registry predates 8928 registry and that is what we want to 
mirror.  I did not spend any time or had anyone recommend investigating 
other possible registries.

> Adding Keccak capabilities to the previous RFCs is a win/win.

Yes indeed.  There is a lack of energy to do it, though.  It seems.

>
>> 3.5.2.  ORCHID Encoding
>
>>   The cSHAKE function call for this update is:
>>       cSHAKE128(Input, L, "", Context ID)
> Is there a way to add a "salt" so that the node may generate more than one ID
> for privacy?

This is used over a broadcast media.  A private salt would really break 
a lot of pieces in the architecture.  I did consider it, but then 
authentication for verification becomes mandatory, and well things 
snowball from there.

>
>> 4.1.  Nontransferablity of DETs
>>    A HI and its HHIT SHOULD NOT be transferable between UA or even
>>    between replacement electronics
> Pro: This answers one question above.
> Con: this bars very interesting IoT use cases I have in mind for spare parts
> and sensory devices. e.g., ISA100.11a uses IPv6 addresses as IDs and would
> benefit from this.

This is for HHITs as DETs.  HHITs (with a different prefix) for other 
stuff could have other behaviors.  I would love to pursue this with you.


> Is the non-transferability a requirement? Could you reword as to say that when
> it is a requirement then the keys must be safeguarded in the store but leave it
> open for other scenarios?

This is kind of buried in the FAA Remote ID rules for Session IDs. We 
skip the whole FAA hand waving and just make the requirement. This is 
taken from 9153 which is 'closer' to FAA (and EASA) rules.

>
>> 4.3.  Remote ID DET as one Class of Hierarchical HITs
>>   UAS Remote ID DET may be one of a number of uses of HHITs.  However,
>>   it is out of the scope of the document to elaborate on other uses of
>>   HHITs.  As such these follow-on uses need to be considered in
>>   allocating the RAAs (Section 3.3.1) or HHIT prefix assignments
>>   (Section 8).
> This answers another of my questions, but then please limit your MUST to the
> supported use case of DETs not for HHITs in general, to my point right above.

this is in the "HHITs as DETs" section, and thus I thought it would be 
limited.


>
>> 6.  Other UTM Uses of HHITs Beyond DET
>> Please expand UTM (and add to terminology?)

I wonder at what point this got cut?  Ah, UTM is one of the BIG terms 
defined in 9153 that we point to in the beginning of Definitions.  I was 
told to remove duplicate defs.  I will expand:

UAS Traffic Management (UTM) in this first use.

>
> 8.2.  New IANA DRIP Registry
>
>
>   >   Hierarchical HIT (HHIT) Suite ID:
>
>   >      HHIT Suite          Value
>
>   You probably want an  additional column with ref to the algorithms, or maybe
>   reuse either the format or registry  of RFC 8928, more below.

This mirrors 7401 HIP registry which predates 8928.

I question the value, here in this registry, to go back to where each of 
these are defined.  Other than the referenced rfcs?

>
>> 8.4.  IANA HIP Registry Updates
>>   EdDSA Curve Label:
> Any way to use / extend
> https://www.rfc-editor.org/rfc/rfc8928.html#name-crypto-type-subregistry
> ?

No.  I have problems with that registry and do not want to conflict it 
with the goals here.

>
>> 9.  Security Considerations
>>   The 64-bit hash in HHITs presents a real risk of second pre-image
>>   cryptographic hash attack Section 9.4.
> This partially addresses another of my earlier questions.


Yes.  See that I did take this to CFRG and following what we covered there.

>
>>   However, with today's computing power, producing 2^64 EdDSA keypairs
>>   and then generating the corresponding HHIT is economically feasible.
> That would be 2^60, unless I miss something? and then maybe there'd be a way to
> variate other fileds of the hash with the same key.
> Then there's the post Quantum thingy. I guess it's safe to say that this model
> is not post-Q resilent right?

No 2^64.  That was a error up there in Fig 1.  Thanks for catching that.

Not PQ resilient.  No viable PQC solution at this point that we can 
shoehorn into this small size dictated by other regulations.  One one 
hits the surf, we can allocate a HHSI for it.

>
>>   The Registry service [drip-registries], through its HHIT
>>   uniqueness enforcement, provides against forced or accidental HHIT
>>   hash collisions.
> When it's reachable. When it's not, there can be both impersonation and DOS
> attacks based on the false ID.

This is where drip-auth comes in.  With its HDA-UA Broadcast Attestation 
(appdx B), a small cache of HDA HHIT/HI would provide the needed protection.

We specifically considered how this would work with no Internet access 
to the Observer.  Either because they were in some National Park with no 
access, or a natural disaster with everything down, we designed for an 
approach that worked 'offline'.

But you have to get into the weeds.  drip-rid only sets the stage.


>
>> 9.3.  Privacy Considerations
>>   There is no expectation of privacy for DETs; it is not part of the
>>   privacy normative requirements listed in, Section 4.3.1, of
>>   [RFC9153].
> This addresses another of my initial questions.

This is over a broadcast media.  What are we suppose to do?  Totally 
blind it?  FAA (and those they proxy for) would not allow this. Well 
they do provide for UUID usage, but then this is supposed to only be 
used for where it can publicly be linked.


>
>>   DETs are broadcast in the clear over the open air via
>>   Bluetooth and Wi-Fi.
> So L2 security when present still protects the ID but not MAC, correct?

Show me an L2 security over a broadcast media.  Yes we kind of did it 
for 802.1AE, but then it is a small group that shares the key. Here it 
has to be for anyone listening and that means no real security.

And MAC is always exposed.  There are claims of L1 security, but those 
are really special cases for P2P links.


>
>> 9.4.  Collision Risks with DETs
>>    The 64-bit hash size does have an increased risk of collisions over
>>    the 96-bit hash size used for the other HIT Suites.
> Is that true also for voluntary collisions (brute force) ?

?  that is what this section is about.  Straight probability stuff. What 
can be brute forced?


>> 10.2.  Informative References
>                unmanned-aerial-systems-serial-numbers>.


I do not get this question.  What do you want to know?  xml2rfc wraps 
the URL this way.

>
>>   [drip-architecture]
> Shouldn't be normative?
>
>>   [drip-authentication]
> Same, and then for registries?

Answered by wg chair.

I hope this helps and I look forward to your responses.

Bob