Re: [Drip] Handling appendices (was RE: Iotdir early review of draft-ietf-drip-rid-07)

[Robert Moskowitz <[e-mail]>]

Below is the revised ToC.  APpendix B should be merged into sec 6 at 
some point.

As to Host_ID, I started using it in '98.  It was one of the namespaces 
in the IAB Namespace Research Group.  Others have latched on to it over 
the years, but ...

Table of Contents

    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
      1.1.  Nontransferablity of HHITs  . . . . . . . . . . . . . . .   4
    2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   4
      2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   4
      2.2.  Notations . . . . . . . . . . . . . . . . . . . . . . . .   4
      2.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
    3.  The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . .   6
      3.1.  HHIT prefix . . . . . . . . . . . . . . . . . . . . . . .   6
      3.2.  HHIT Suite IDs  . . . . . . . . . . . . . . . . . . . . .   7
        3.2.1.  8 bit HIT Suite IDs . . . . . . . . . . . . . . . . .   7
      3.3.  The Hierarchy ID (HID)  . . . . . . . . . . . . . . . . .   7
        3.3.1.  The Registered Assigning Authority (RAA)  . . . . . .   7
        3.3.2.  The Hierarchical HIT Domain Authority (HDA) . . . . .   8
      3.4.  Edward Digital Signature Algorithm for HITs . . . . . . .   8
        3.4.1.  HOST_ID . . . . . . . . . . . . . . . . . . . . . . .   8
        3.4.2.  HIT_SUITE_LIST  . . . . . . . . . . . . . . . . . . .   9
      3.5.  ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . .   9
        3.5.1.  Adding additional information to the ORCHID . . . . .  10
        3.5.2.  ORCHID Encoding . . . . . . . . . . . . . . . . . . .  11
        3.5.3.  ORCHID Decoding . . . . . . . . . . . . . . . . . . .  13
        3.5.4.  Decoding ORCHIDs for HITv2  . . . . . . . . . . . . .  13
      3.6.  Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . .  13
    4.  Hierarchical HITs as Remote ID  . . . . . . . . . . . . . . .  14
      4.1.  Hierarchical HITs encoded as CTA-2063-A Serial Numbers .  14
      4.2.  Remote ID as one class of Hierarchical HITs . . . . . . .  14
      4.3.  Hierarchy in ORCHID Generation  . . . . . . . . . . . . .  15
      4.4.  Hierarchical HIT Registry . . . . . . . . . . . . . . . .  15
      4.5.  Remote ID Authentication using HHITs  . . . . . . . . . .  15
    5.  UAS ID HHIT in DNS  . . . . . . . . . . . . . . . . . . . . .  16
    6.  DRIP Proofs . . . . . . . . . . . . . . . . . . . . . . . . .  17
      6.1.  Claim / Assertion: HHIT . . . . . . . . . . . . . . . . .  17
      6.2.  Self-Attestation: Attestation(X,X)  . . . . . . . . . . .  17
        6.2.1.  Concise Self-Attestation: Attestation(X, ConciseX) .  19
      6.3.  Certificate(X, Y) . . . . . . . . . . . . . . . . . . . .  21
        6.3.1.  Concise Certificate(X, Concise Y) . . . . . . . . . .  22
      6.4.  Offline Broadcast Attestation: Attestation(X, Offline
            Y)  . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
      6.5.  Timestamps  . . . . . . . . . . . . . . . . . . . . . . .  25
      6.6.  Signatures  . . . . . . . . . . . . . . . . . . . . . . .  25
    7.  Other UTM uses of HHITs . . . . . . . . . . . . . . . . . . .  25
    8.  DRIP Requirements addressed . . . . . . . . . . . . . . . . .  25
    9.  ASTM Considerations . . . . . . . . . . . . . . . . . . . . .  25
    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
      10.1.  New IPv6 prefix needed for HHITs . . . . . . . . . . . .  26
    11. Security Considerations . . . . . . . . . . . . . . . . . . .  27
      11.1.  Hierarchical HIT Trust . . . . . . . . . . . . . . . . .  27
      11.2.  Collision risks with Hierarchical HITs . . . . . . . . .  28
      11.3.  Proofs Considerations  . . . . . . . . . . . . . . . . .  28
    12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
      12.1.  Normative References . . . . . . . . . . . . . . . . . .  29
      12.2.  Informative References . . . . . . . . . . . . . . . . .  29
    Appendix A.  EU U-Space RID Privacy Considerations  . . . . . . .  32
    Appendix B.  Example HHIT Self Attestation  . . . . . . . . . . .  32
      B.1.  HHIT Offline Self Attestation . . . . . . . . . . . . . .  33
    Appendix C.  Calculating Collision Probabilities  . . . . . . . .  34
    Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  34
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34


On 7/9/21 11:45 AM, [e-mail] wrote:
> Hi Rob,
>
> To start the discussion, here is my current take on the appendices:
>
>
>     Appendix A.  EU U-Space RID Privacy Considerations  . . . . . . .  13
>
> Med: Can be kept as an appendix.
>
>     Appendix B.  The Hierarchical Host Identity Tag (HHIT)  . . . . .  14
>
> Med: Should definitely move to the main document.
>
>
>     Appendix C.  ORCHIDs for Hierarchical HITs  . . . . . . . . . . .  17
>
> Med: Idem as the previous one.
>
>     Appendix D.  Edward Digital Signature Algorithm for HITs  . . . .  20
>       D.1.  HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . .  21
>
> Med: I would avoid the use of HOST_ID as it conflicts with RFC6967 and many other RFCs.
>
>       D.2.  HIT_SUITE_LIST  . . . . . . . . . . . . . . . . . . . . .  21
>     Appendix E.  Example HHIT Self Attestation  . . . . . . . . . . .  22
>       E.1.  HHIT Offline Self Attestation . . . . . . . . . . . . . .  23
>
> Med: Can be kept as an appendix.
>
>     Appendix F.  DRIP Proofs  . . . . . . . . . . . . . . . . . . . .  24
>       F.1.  Claim / Assertion: HHIT . . . . . . . . . . . . . . . . .  24
>       F.2.  Self-Attestation: Attestation(X,X)  . . . . . . . . . . .  24
>         F.2.1.  Concise Self-Attestation: Attestation(X, ConciseX)  .  26
>       F.3.  Certificate(X, Y) . . . . . . . . . . . . . . . . . . . .  28
>         F.3.1.  Concise Certificate(X, Concise Y) . . . . . . . . . .  29
>       F.4.  Offline Broadcast Attestation: Attestation(X, Offline
>             Y)  . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
>       F.5.  Timestamps  . . . . . . . . . . . . . . . . . . . . . . .  32
>       F.6.  Signatures  . . . . . . . . . . . . . . . . . . . . . . .  32
>
> Med: To be move the main document.
>
>     Appendix G.  Calculating Collision Probabilities  . . . . . . . .  32
>
> Med: To be kept as an appendix.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Robert Moskowitz [mailto:[e-mail]]
>> Envoyé : vendredi 9 juillet 2021 17:35
>> À : Michael Richardson <[e-mail]>; iot-
>> [e-mail]
>> Cc : [e-mail]; [e-mail]
>> Objet : Re: [Drip] Iotdir early review of draft-ietf-drip-rid-07
>>
>>
>>
>> On 7/8/21 12:29 PM, Michael Richardson via Datatracker wrote:
>>> Reviewer: Michael Richardson
>>> Review result: Almost Ready
>>>
>>> Reviewer: Michael Richardson
>>>
>>> Review result: Ready with Nits
>>> Document: draft-ietf-drip-rid-07
>>> Summary: Almost Ready
>>>
>>> I have done an IoT-Directorate review of draft-ietf-drip-rid-07.
>>> I think that I have previously read the document prior to WG
>> adoption.
>>> While the core content of the document is all present, and it
>> would
>>> appear that code could be written from it,  the text in the
>> document
>>> is pretty rough shape.
>>>
>>> The document needs an editorial pass to make the language a bit
>> less abrupt.
>>> There is a lot of content in the appendixes (more than 70% or so),
>> and
>>> I didn't see a lot of forward references to them.  Do we need them
>> all?
>>
>> Much of the appendices came from merging documents.  I am waiting to
>> see what feedback I get on what should be moved into the core doc.
>> And appendices E & F need to be merged into one, as they came from
>> different source documents.
>>
>>
>>>
>>> Nits:
>>>
>>> I stumbled on the very first sentence:
>>>
>>>     [drip-requirements] describes a UAS ID as a "unique (ID-4),
>> non-spoofable
>>>     (ID-5), and identify a registry where the ID is listed (ID-2)";
>> all within
>>>             ^^^^^^^^^^^^^^^ <- just does not flow with the rest of
>> the sentence.
>>>     a 20 character Identifier (ID-1).
>>>
>>> In general, I'd rather that the first word wasn't a reference.
>>> Maybe just move that sentence to the end of the Introduction, or
>> at
>>> least maybe two or three paragraphs down.
>>>
>>> s/This is in contrast to general IDs (e.g. a UUID or device serial
>> number) as
>>>          the subject in an X.509 certificate./
>>>     This is in contrast to using general IDs (e.g. a UUID or device
>> serial number) as
>>>          the subject in an [RFC5280] X.509 certificate./
>>>
>>> a) please expand "CA" in the intro on first use.
>>> b) please consider if this just belongs in Security
>> Considerations.
>>>      "In a multi-CA PKI, a subject can occur in multiple CAs,
>> possibly
>>>      fraudulently. CAs within the PKI would need to implement an
>> approach to
>>>      enforce assurance of uniqueness."
>> In review of this para and comments, I can see this needs a good
>> rewrite.  Again, it came from multiple sources and is a bit of a
>> mashup.
>>
>>> Maybe write:
>>>      "The use of multiple Certification Authorities (CA), such as
>> used for the
>>>      public WebPKI comes with the risk of duplicates among the
>> different CAs.
>>>      These can occur due to fraud or error, and to date the WebPKI
>> has not
>>>      found a way to prevent this, only to detect the occurance
>> afterwards.
>>>      [reference to certtrans]
>>>
>>> } 1.1. Nontransferablity of HHITs
>>> } HIs and its HHITs SHOULD NOT be transferable between UA or even
>>> between } replacement electronics for a UA. The private key for
>> the HI
>>> SHOULD be held } in a cryptographically secure component.
>>>
>>> I agree that this is true.  But, I think that some additional
>>> explanation is waranteed.  I know that we had the discussion about
>>> rebuilding entire air frames, where every single component is
>> changed,
>>> and yet, it's the same airframe.
>> ok.
>>
>>> } TYPE-3
>>> } A UTM system assigned UUID [RFC4122], which can but need not be
>> dynamic.
>>> maybe write:
>>>         A UTM system assigned UUID [RFC4122]. These can be dynamic,
>> but
>>>         do not need to be.
>>>
>>> } 3.1. Hierarchical HITs encoded as CTA-2063-A Serial Numbers
>>>
>>> please give me an example of a CTA-2063-A serial number, and
>> please
>>> give me an example of a HHIT encoded as one.... AHA. Appendix B.4,
>> so
>>> a forward reference, please?... ah, but no actual example in B.4.
>> AX Enterprize now has its own manufacturer code so we can now
>> generate examples.  This is recent.
>>
>>> 3.3:
>>> } The justification then was attacks against these fields are DoS
>> attacks
>>>     against protocols using them.
>>>
>>> Please reword, as this doesn't look like a sentence to me.
>>>
>>> } The individual HHITs are potentially too numerous (e.g. 60 -
>> 600M)
>>> and } dynamic to actually store in a signed, DNS zone.
>>>
>>> This point has been disputed before. .com is much larger,  and we
>>> don't have 600M of them on day one.  I.e. by the time we really
>> have
>>> 600M of them, then there will be a business justification for
>> investing in the required hardware.
>>
>> I lost track that .com has grown that large.  But I realize that
>> point that is needed is the timing of additions.  A HHIT as a short-
>> live Session ID could be requested minutes before the flight. And
>> these can keep coming in every few minutes through the course of the
>> day, making zone signing really challenging.  Or so it seems to me?
>>
>>> section 9, please start by explaining what a HHIT hijacking *is*,
>> and what
>>>           the operational impact of such a thing occuring is.
>>>
>>>
>>>
>>>
>>>
>> Anything I did not respond to here is a comment I will work on.
>>
>> Thanks
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>