Early Review of draft-ietf-drip-auth-05
review-ietf-drip-auth-05-secdir-early-salz-2022-03-22-00
| 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 | 2024-06-26 (Latest revision 2024-02-21) | |
| Completed reviews |
Tsvart IETF Last Call review of -43
by Gorry Fairhurst
(diff)
Dnsdir IETF 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) |
|
| Comments |
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 | https://mailarchive.ietf.org/arch/msg/secdir/tbXK2CktKCdyYlFc46EpF-9aUjk | |
| Reviewed revision | 05 (document currently at 49) | |
| Result | Has issues | |
| Completed | 2022-03-22 |
review-ietf-drip-auth-05-secdir-early-salz-2022-03-22-00
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.