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

["Card, Stu" <[e-mail]>]

The only point on which I will respond without getting some sleep first is
expansion of ASTM.
Originally, it was an acronym for "the American Society for Testing and
Materials".
However, it is no longer such; the full name of the organization is now
"ASTM International".
The other points will require more thought. ;-) Thanks for the quick review!


On Wed, Mar 23, 2022 at 3:49 AM <[e-mail]> wrote:

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