Skip to main content

Early Review of draft-ietf-drip-auth-05

Request Review of draft-ietf-drip-auth-05
Requested revision 05 (document currently at 49)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2022-03-22
Requested 2022-03-08
Requested by Mohamed Boucadair
Authors Adam Wiethuechter , Stuart W. Card , Robert Moskowitz
I-D last updated 2022-03-22
Completed reviews Tsvart Last Call review of -43 by Gorry Fairhurst (diff)
Dnsdir Last Call review of -43 by Di Ma (diff)
Dnsdir Telechat review of -46 by Di Ma (diff)
Iotdir Telechat review of -45 by Behcet Sarikaya (diff)
Intdir Telechat review of -46 by Carlos J. Bernardos (diff)
Secdir Early review of -05 by Rich Salz (diff)
Genart Early review of -24 by Matt Joras (diff)
We are seeking for a security review to help the WG identify potential issues and fix them early in the process.   

It would be helpful to read first RFC9153 and draft-ietf-drip-arch to get familiar with the context. 

Many thanks for your help.
Assignment Reviewer Rich Salz
State Completed
Request Early review on draft-ietf-drip-auth by Security Area Directorate Assigned
Posted at
Reviewed revision 05 (document currently at 49)
Result Has issues
Completed 2022-03-22
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

Sec 3.3.2 the constraints/requirements should be first.

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