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

[Rich Salz via Datatracker <[e-mail]>]

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.