Re: [Drip] Secdir early review of draft-ietf-drip-auth-05

[Adam Wiethuechter <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, March 22, 2022 11:24 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Secdir early review of draft-ietf-drip-auth-05

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.

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

ASTM needs to be expanded.

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

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

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

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.

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

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

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

Sec 3.3.2 the constraints/requirements should be first.

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

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.

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

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.

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

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?

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

Sec 6.3.5.1 "multiplexing" seems out of place.

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

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

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

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

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

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.

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