Subject: [Iot-directorate] Iotdir early review of draft-ietf-drip-rid-07

From: Michael Richardson via Datatracker <[email-masked]>
Date: Thu, 08 Jul 2021 09:29:35 -0700

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?

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

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.

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

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.

section 9, please start by explaining what a HHIT hijacking *is*, and what
        the operational impact of such a thing occuring is.

---

From: <[email-masked]>
Date: Fri, 9 Jul 2021 05:38:41 +0000

Hi Michael, 

Many thanks for the review and for providing it in a timely manner. Much appreciated!

All the points you raised are good ones. I trust the authors will engage and propose changes.

For the material in the appendixes, the WG need to decide which ones have to move to the core of the document. 

Please don't be surprised if you don't see any revised version by the cutoff date. The plan is to release a revised version that addresses your review (and the pending secdir review) in the IETF week.

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Michael Richardson via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 8 juillet 2021 18:30
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Iotdir early review of draft-ietf-drip-rid-07
> 
> 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.
> 
> 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?
> 
> 
> Nits:
> 
> Maybe just move that sentence to the end of the Introduction, or at
> least maybe two or three paragraphs down.
> 
> } 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.
> 
> } TYPE-3
> 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.
> 
> 3.3:
> } 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.
> 

_________________________________________________________________________________________________________________________

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: Fri, 9 Jul 2021 09:13:21 -0400

> For the material in the appendixes, the WG need to decide which ones have to move to the core of the document.

Much of the appendices are from merged documents.  I put the merged 
material there to allow for the WG to contribute what they see as core 
to RID and what is supporting material.

Stay tuned, but all chime in on thoughts about organization.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Jul 2021 11:35:24 -0400

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

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

> frames, where every single component is changed, and yet, it's the same

ok.

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

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

>          the operational impact of such a thing occuring is.

Anything I did not respond to here is a comment I will work on.

Thanks

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jul 2021 12:25:18 -0400

> For the material in the appendixes, the WG need to decide which ones
    > have to move to the core of the document.

I saw the beginning of that thread.

    > Please don't be surprised if you don't see any revised version by the
    > cutoff date. The plan is to release a revised version that addresses
    > your review (and the pending secdir review) in the IETF week.

:-)

"So many drafts, so little time"

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jul 2021 12:26:51 -0400

Robert Moskowitz <[email-masked]> wrote:
    >> 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.

It's hard to know how much is even needed (in an appendix or in the body), as
I think that much of the knowledge would come from the HHIT RFC anyway.

---

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

> The document needs an editorial pass to make the language a bit less abrupt.

Med gave me some edits and I have done one read-through. but it needs 
more.  Hard to do on the train.  Solid read-through after I push out -08.

> didn't see a lot of forward references to them.  Do we need them all?

addressed.

> maybe two or three paragraphs down.

rewritten.  Please check out -08 when it comes out.

>         the subject in an [RFC5280] X.509 certificate./

This and other changes.

>     found a way to prevent this, only to detect the occurance afterwards.

Text change.  please rereview.

> frames, where every single component is changed, and yet, it's the same

Still struggling with this one.

>        A UTM system assigned UUID [RFC4122]. These can be dynamic, but

done

> reference, please?... ah, but no actual example in B.4.

Working on a script to make these.  Consolidated the 2 places where this 
is covered.

> Please reword, as this doesn't look like a sentence to me.

Some done.

> will be a business justification for investing in the required hardware.

It seems to be more a signing challenge when there is no pause in 
updates.  Some HIDs will be very stable and signing easy even if very 
large.  Others could have an add a minute, every minute of the year...

>          the operational impact of such a thing occuring is.

text changed.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jul 2021 21:22:37 -0400

Robert Moskowitz <[email-masked]> wrote:
    >> } 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.
    >>
    >> rebuilding entire air frames, where every single component is changed,
    >> and yet, it's the same airframe.

    > Still struggling with this one.

I think that it's not a solveable problem.
You should punt to someone who can form blue ribbon committees to determine
the truth!

Until then, "when critical core electronics are replaced, a new private key occurs,
       and this results in a new HHIT, and a new identity. Such electronics
       should be clearly marked so that operators/aviators are not surprised"

Of course, there is a Star Wars / Buck Rogers plot here involving stolen
droids^Wairframes here, so just try to make sure it gets filmed in Vancouver,
and has a funny self-deprecating robot in it.
. o O ( "It's an old code sir, but it checks out" )

looking forward to reading the diff.