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

[[e-mail]]

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 <[e-mail]>
> Envoyé : mardi 22 mars 2022 16:24
> À : [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : 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.
> 
> 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.
> 
> 


_________________________________________________________________________________________________________________________

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.