Subject: [secdir] Secdir early review of draft-ietf-drip-auth-05

From: Rich Salz via Datatracker <[email-masked]>
Date: Tue, 22 Mar 2022 08:24:06 -0700

Reviewer: Rich Salz
Review result: Has Issues

I know nothing about DRIP. I skimmed RFC 9153 and the suggested draft.
Take thesze comments with appropriate skepticism.

ASTM needs to be expanded.

Are "pages" basically packets? A confirmation/explanation, perhaps in the
definitions section would help. The definitions points to drip-requirements
draft, but then documents "aircraft"?  Really? :)

There are far too many one-paragraph sections.  Come up with broader titles
and merge things a bit; I think it will read better. I know kthis is not a
trivial amount of work.

Sec 3.3.1: the bit numbering is opposite of what I'm used to (i.e., 31->0,
this is 0->31).  This holds for all other ascii-art protocol blocks.
Consider breaking up the top byte into two nibbles AH and PH Pad out AuthType
into

Sec 3.3.2 the constraints/requirements should be first.

Sec 4.1.2.1 Put spaces between the logical parts of the bytes:
	12 50098960bf8c0504200100100 0a00145aac6b00abba268b7
Is that correct?  Why only the last 23?  Maybe I am missing some
other checksum, or don't know enough about Reed-Solomon.

Sec 5, "UNIX timestamp offset by ..." you mean Unix-style timestamp
but with an epoch of ... right?  Is the "UA signature" defined
somewhere?  Same question about the signatures in Sec 6, etc.

Related question, where are the algorithms for the "Message Hash"
and other hashes within the doc defined?  Should be a forward reference.
Or worse, it's an external reference?

Sec 6.3.5.1 "multiplexing" seems out of place.

General comment, putting all limitations, constraints, requirements, etc.,
should be up front.

Is Appendix A useful here?  I don't see how.

The sample messages in C do not seem useful, as they seem to be repeating
just the packet layouts.  I do not understand what the "Hex" values in
C.3 mean and there seems to be no way to re-compute/verify them.

---

From: <[email-masked]>
Date: Wed, 23 Mar 2022 07:49:22 +0000

Hi Rich, 

It was really a challenge to request this review (2022-03-08) with a suggested deadline of 2022-03-22 and get it done before our session (2022-03-23). So, many thanks for sharing your review in a timely manner.

All good comments and fair questions. I trust the pen holders will follow-up SOON (*). 

Cheers,
Med	

> -----Message d'origine-----
> De : Rich Salz via Datatracker <[email-masked]>
> Envoyé : mardi 22 mars 2022 16:24
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Secdir early review of draft-ietf-drip-auth-05
> 
> Reviewer: Rich Salz
> Are "pages" basically packets? A confirmation/explanation, perhaps in
> the definitions section would help. The definitions points to drip-
> requirements draft, but then documents "aircraft"?  Really? :)
> 
> There are far too many one-paragraph sections.  Come up with broader
> titles and merge things a bit; I think it will read better. I know kthis
> is not a trivial amount of work.
> 
> Sec 3.3.1: the bit numbering is opposite of what I'm used to (i.e., 31-
> >0, this is 0->31).  This holds for all other ascii-art protocol blocks.
> Consider breaking up the top byte into two nibbles AH and PH Pad out
> AuthType into
> 
> 	12 50098960bf8c0504200100100 0a00145aac6b00abba268b7 Is that
> correct?  Why only the last 23?  Maybe I am missing some other checksum,
> or don't know enough about Reed-Solomon.
> 
> Sec 5, "UNIX timestamp offset by ..." you mean Unix-style timestamp but
> with an epoch of ... right?  Is the "UA signature" defined somewhere?
> Same question about the signatures in Sec 6, etc.
> 
> General comment, putting all limitations, constraints, requirements,
> etc., should be up front.
> 
> The sample messages in C do not seem useful, as they seem to be
> repeating just the packet layouts.  I do not understand what the "Hex"
> values in

_________________________________________________________________________________________________________________________

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: "Card, Stu" <[email-masked]>
Date: Wed, 23 Mar 2022 11:56:06 -0400

The only point on which I will respond without getting some sleep first is
expansion of ASTM.
Originally, it was an acronym for "the American Society for Testing and
Materials".
However, it is no longer such; the full name of the organization is now
"ASTM International".
The other points will require more thought. ;-) Thanks for the quick review!

On Wed, Mar 23, 2022 at 3:49 AM <[email-masked]> wrote:

> Hi Rich,
>
> It was really a challenge to request this review (2022-03-08) with a
> suggested deadline of 2022-03-22 and get it done before our session
> (2022-03-23). So, many thanks for sharing your review in a timely manner.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Mar 2022 15:57:52 +0000

*   Originally, it was an acronym for "the American Society for Testing and Materials".
However, it is no longer such; the full name of the organization is now "ASTM International".
The other points will require more thought. ;-) Thanks for the quick review!

Aha, so just like ISO/OSI. :)

---

From: Adam Wiethuechter <[email-masked]>
Date: Wed, 23 Mar 2022 16:26:28 +0000

Rich,

Thanks for the first external review of the document! My comments are inline.

I should have a new version by end of next week.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Rich Salz via Datatracker <[email-masked]>
Sent: Tuesday, March 22, 2022 11:24 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Secdir early review of draft-ietf-drip-auth-05

Reviewer: Rich Salz

<atw>
Will do - it is a fair bit to grok so understandable.
</atw>

<atw>
I saw Stu responded to this for you.
</atw>

<atw>
The Authentication Pages could be considered packets (especially on Bluetooth 4). They are part of a much larger Bluetooth framing structure that it is sent in a single shot.

The 'aircraft' definition is probably unnecessary at this point and I will make it an action item to remove it and fix any text that needs adjusting because of it. To be honest it was me being lazy and not wanting to comb the document to add "Unmanned" in front of every instance.
</atw>

<atw>
This was a stylistic choice on my part so good to hear some feedback on it.

My intention was that specific fields that are later referenced in the document to explicitly state what nests into what would be easier with section headers for them rather than pointing to a general section and have to dig through some text in section to figure things out.

I will play with collapsing some of them and seeing how it flows.
</atw>

<atw>
I will double check but the document we work from (ASTM F3411) is 0->31 and not the IETF convention of 31->0. This threw me off too at first. I can easily flip it as it really doesn't matter either way I think.
</atw>

<atw>
This is a hard section to find a place. A new reader with no context of the fields I reference could find the text puzzling to understand. This was why I place it at the end of section 3 rather than the beginning.

I will see if I can do some re-arrangements. I suppose forward references aren't the worst thing.
</atw>

<atw>
The correct breakdown of the line you have is this:
12 50 098960bf8c05 042001001000a00145aac6b00abba268b7

The last 23-bytes are used as the first two bytes are well known to a receiver. The first byte being Protocol Version and Message Type - this won't change in the middle of a Authentication Message from a transmitter and it has other pages to reference to get the value. The second byte is the AuthType and Page Number - AuthType does not change in a message being reconstructed while Page Number is contextual. If there are 3 pages (0 indexed) and you only received Page 0 and Page 2 - then the missing one is Page 1. For these reasons there is no need to perform the Reed Solomon FEC operation over the bytes - there used to be more explicit text about this - perhaps it got lost?

I think this indicates the text in this section still needs work and more detailed reviews from others.
</atw>

<atw>
Yes a Unix-style timestamp. I will adjust the wording.

The structure in Section 5 is more formally defined in draft-ietf-drip-registries. This section is more of an abbreviated "copy-paste" of it so its inline in this document. It's just in this document I explicitly set certain field values that are different from the other document.
</atw>

<atw>
The algorithm for the Message Hash is bound to the hash algorithm used to generate the DET. This is defined in draft-ietf-drip-uas-rid. So its an external reference that needs to be more well explained and called out.
</atw>

<atw>
Perhaps it is the wrong word here. Sub-type is probably the better term.
</atw>

<atw>
Understood. To me it seems a bit odd to have Section 7 near the top but perhaps forward referencing into the document is not the worst thing in this case if the implementation makes his choice from that section and just clicks the link to go to the relevant section to know implementation details.

Guess I am old school and read the full document first and attempt to understand everything the author wrote and tried to convey rather than jump around sections. :-)
</atw>

<atw>
ASTM F3411 Authentication has really only 3 states: None, Invalid or Valid. This is because under ASTM the idea is that Authentication is done by an external service hosted somewhere on the Internet so you will always get some sort of answer back. With DRIP this classification becomes more complex as we support "offline" scenarios where the receiver does not have Internet connectivity. Since we are using asymmetric keys this means the public key must somehow be obtained - DRIP Registries gets more into detail how these keys are stored on DNS and one reason for DRIP Authentication is to send the key over Broadcast RID.

There are two keys of interest: the PK of the UA and the PK of the HDA (or Registry). The draft gives a clear way to send the PK of the UA over the Broadcast RID messages - however the PK of the Registry is not. It can be using the same mechanism but is not required to do so due to potential operational constraints and implementation of a given UA transmitter. As such there are scenarios where you may have part of the key-chain but not all of it.

The intent of Appendix A is to give some kind of recommended way to classify these various states and convey it to the user through colors and state names/text.

I will add some introductory text in this area to better explain why it is included at all.
</atw>

<atw>
They were added to give context for someone who may have a hard time grokking the packet layouts and the various nesting. The hex values were taken from a running implementation log of such messages to give an example of what would be seen over the air.
</atw>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Mar 2022 16:35:20 +0000

Thanks for giving the feedback consideration.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 23 Mar 2022 12:45:51 -0400

Just a quick comment.

On Wed, Mar 23, 2022 at 12:26 PM Adam Wiethuechter
<[email-masked]> wrote:
> ...
> ...

Maybe I am confused, but I believe the IETF usual bit ordering is from
0 at the left through 31 (or 15 or whatever) at the right. So the
diagrams in this draft look perfectly normal and expected to me.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]