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

From: <[email-masked]>
Date: Fri, 9 Jul 2021 15:45:42 +0000

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:[email-masked]]
> Envoyé : vendredi 9 juillet 2021 17:35
> À : Michael Richardson <[email-masked]>; iot-
> [email-masked]
> Cc : [email-masked]; [email-masked]
> 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.

---

From: <[email-masked]>
Date: Fri, 9 Jul 2021 16:50:56 +0000

Re-,

One comment inline. 

Cheers,
Med

> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : vendredi 9 juillet 2021 17:46
> À : Robert Moskowitz <[email-masked]>
> Objet : Handling appendices (was RE: [Drip] Iotdir early review of
> draft-ietf-drip-rid-07)
> 
> 

[Med] I just saw that HOST_ID is already in rfc7401#section-5.2.9. So, it is too late to avoid.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Jul 2021 14:08:27 -0400

> [Med] I just saw that HOST_ID is already in rfc7401#section-5.2.9. So, it is too late to avoid.

Or in RFC5201 in 5.2.8?

Anyone else use it earlier?  And I know I can find HIP drafts from the 
beginning where we used Host_ID.

If I try really hard I should be able to find emails I had with Touch 
about "Host ID" from when I started this.

It is just too good of a label for these sorts of things.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Jul 2021 15:12:19 -0400

I will work on this after I get through your comments.

Only so much I can do while dividing my time with the grandkids here.

They are munching on pizza, so I should be able to get through another 
comment or two!

:)

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

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 12 Jul 2021 16:52:35 -0400

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

---

From: <[email-masked]>
Date: Tue, 13 Jul 2021 05:28:43 +0000

Hi Bob, 

This looks good. Thanks. 

One comment though, I would move 1.1 and position it after we introduce HHIT.

Appendix B is fine where it is now. 

Cheers,
Med

> Envoyé : lundi 12 juillet 2021 22:53
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Objet : Re: Handling appendices (was RE: [Drip] Iotdir early review
> of draft-ietf-drip-rid-07)
> 
> 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
> 
> >     Appendix A.  EU U-Space RID Privacy Considerations  . . . . .
> . .
> > 13
> >
> >     Appendix B.  The Hierarchical Host Identity Tag (HHIT)  . . .
> . .
> > 14
> >
> >     Appendix C.  ORCHIDs for Hierarchical HITs  . . . . . . . . .
> . .
> > 17
> >
> >       D.1.  HOST_ID . . . . . . . . . . . . . . . . . . . . . . .
> . .
> > 21
> >
> >       E.1.  HHIT Offline Self Attestation . . . . . . . . . . . .
> . .
> > 23
> >
> >       F.6.  Signatures  . . . . . . . . . . . . . . . . . . . . .
> . .
> > 32
> >
> >     Appendix G.  Calculating Collision Probabilities  . . . . . .
> . .
> > 32
> >
> >> De : Robert Moskowitz [mailto:[email-masked]] Envoyé :
> >> vendredi 9 juillet 2021 17:35 À : Michael Richardson
> >> <[email-masked]>; iot- [email-masked] Cc :
> >> [email-masked]; [email-masked] Objet : Re:
> [Drip]
> >> Iotdir early review of draft-ietf-drip-rid-07
> >>
> >>
> >>
> ____________________________________________________________________
> __
> > ___________________________________________________
> >
> > 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.
> >

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 13 Jul 2021 08:12:01 -0400

> One comment though, I would move 1.1 and position it after we introduce HHIT.

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