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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Pascal, for your review and thank you, Bob, for updating the I-D based on Pascal's review.

Good work by the two of you ;-)

Based on the -28 version, this document seems ready to advance to IESG evaluation.

Regards

-éric


-----Original Message-----
From: Pascal Thubert via Datatracker <[e-mail]>
Reply to: Pascal Thubert <[e-mail]>
Date: Monday, 16 May 2022 at 15:30
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Intdir last call review of draft-ietf-drip-rid-26
Resent from: <[e-mail]>
Resent to: Erik Kline <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, Eric Vyncke <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent date: Monday, 16 May 2022 at 15:30

    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?