[Int-dir] Intdir last call review of draft-ietf-drip-rid-26

[Pascal Thubert via Datatracker <[e-mail]>]

Reviewer: Pascal Thubert
Review result: Ready with Nits


https://www.ietf.org/id/draft-ietf-drip-rid-26.txt









DRIP                                                        R. Moskowitz
Internet-Draft                                            HTT Consulting
Updates: 7401, 7343 (if approved)                                S. Card
Intended status: Standards Track                         A. Wiethuechter
Expires: 14 November 2022                             AX Enterprize, LLC
                                                               A. Gurtov
                                                    Linköping University
                                                             13 May 2022


 DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
                         draft-ietf-drip-rid-26

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

   This document updates RFC7401 and RFC7343.

   Within the context of RID, HHITs will be called DRIP Entity Tags
   (DETs).  HHITs self-attest to the included explicit hierarchy that
   provides registry (via, e.g., DNS, EPP) discovery for 3rd-party
   identifier attestation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 November 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Moskowitz, et al.       Expires 14 November 2022                [Page 1]

Internet-Draft            DRIP Entity Tag (DET)                 May 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  HHIT Statistical Uniqueness different from UUID or X.509
           Subject . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   4
     2.2.  Notations . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . .   6
     3.1.  HHIT Prefix for RID Purposes  . . . . . . . . . . . . . .   7
     3.2.  HHIT Suite IDs  . . . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  HDA custom HIT Suite IDs  . . . . . . . . . . . . . .   8
     3.3.  The Hierarchy ID (HID)  . . . . . . . . . . . . . . . . .   8
       3.3.1.  The Registered Assigning Authority (RAA)  . . . . . .   8
       3.3.2.  The Hierarchical HIT Domain Authority (HDA) . . . . .   9
     3.4.  Edward-Curve Digital Signature Algorithm for HHITs  . . .   9
       3.4.1.  HOST_ID . . . . . . . . . . . . . . . . . . . . . . .  10
       3.4.2.  HIT_SUITE_LIST  . . . . . . . . . . . . . . . . . . .  11
     3.5.  ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . .  11
       3.5.1.  Adding Additional Information to the ORCHID . . . . .  12
       3.5.2.  ORCHID Encoding . . . . . . . . . . . . . . . . . . .  13
       3.5.3.  ORCHID Decoding . . . . . . . . . . . . . . . . . . .  15
       3.5.4.  Decoding ORCHIDs for HIPv2  . . . . . . . . . . . . .  15
   4.  Hierarchical HITs as DRIP Entity Tags . . . . . . . . . . . .  15
     4.1.  Nontransferablity of DETs . . . . . . . . . . . . . . . .  16
     4.2.  Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . .  16
     4.3.  Remote ID DET as one Class of Hierarchical HITs . . . . .  17
     4.4.  Hierarchy in ORCHID Generation  . . . . . . . . . . . . .  17
     4.5.  DRIP Entity Tag (DET) Registry  . . . . . . . . . . . . .  18
     4.6.  Remote ID Authentication using DETs . . . . . . . . . . .  18
   5.  DRIP Entity Tags (DETs) in DNS  . . . . . . . . . . . . . . .  18
   6.  Other UTM Uses of HHITs Beyond DET  . . . . . . . . . . . . .  20
   7.  Summary of Addressed DRIP Requirements  . . . . . . . . . . .  20
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     8.1.  New Well-Known IPv6 prefix for DETs . . . . . . . . . . .  20
     8.2.  New IANA DRIP Registry  . . . . . . . . . . . . . . . . .  21
     8.3.  IANA CGA Registry Update  . . . . . . . . . . . . . . . .  22
     8.4.  IANA HIP Registry Updates . . . . . . . . . . . . . . . .  22



Moskowitz, et al.       Expires 14 November 2022                [Page 2]

Internet-Draft            DRIP Entity Tag (DET)                 May 2022


     8.5.  IANA IPSECKEY Registry Update . . . . . . . . . . . . . .  23
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     9.1.  DET Trust in ASTM messaging . . . . . . . . . . . . . . .  25
     9.2.  DET Revocation  . . . . . . . . . . . . . . . . . . . . .  25
     9.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  26
     9.4.  Collision Risks with DETs . . . . . . . . . . . . . . . .  27
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     10.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Appendix A.  EU U-Space RID Privacy Considerations  . . . . . . .  31
   Appendix B.  The 14/14 HID split  . . . . . . . . . . . . . . . .  31
   Appendix C.  Calculating Collision Probabilities  . . . . . . . .  33
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34





> 1.  Introduction

>   DRIP Requirements [RFC9153] describe an Unmanned Aircraft System

Maybe expand DRIP on first use?


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


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

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


> 2.  Terms and Definitions

A forward ref to fig 1 woudl help with all the bit fields.


>  Keccak (KECCAK Message Authentication Code):

I guess the expansion in () is a CC from the next definition.


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



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



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?

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




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




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

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?





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




> 6.  Other UTM Uses of HHITs Beyond DET

> Please expand UTM (and add to terminology?)


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.




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

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

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


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



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


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


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



> 10.2.  Informative References

              unmanned-aerial-systems-serial-numbers>.

>  [drip-architecture]

Shouldn't be normative?

>  [drip-authentication]

Same, and then for registries?