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

[Robert Moskowitz <[e-mail]>]

On 7/13/21 1:28 AM, [e-mail] wrote:
> Hi Bob,
>
> This looks good. Thanks.
>
> One comment though, I would move 1.1 and position it after we introduce HHIT.

Yes, I see that now.  Will do...

>
> Appendix B is fine where it is now.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Robert Moskowitz [mailto:[e-mail]]
>> Envoyé : lundi 12 juillet 2021 22:53
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>> Cc : [e-mail]; [e-mail]
>> Objet : Re: Handling appendices (was RE: [Drip] Iotdir early review
>> of draft-ietf-drip-rid-07)
>>
>> 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.
>>>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit