Re: [Int-dir] Intdir telechat review of draft-ietf-drip-auth-46

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Thanks Med. I guess this is OK, though I personally believe some additional
text (or maybe putting some disclaimer in the Security Considerations
section) would be helpful.

Carlos

On Tue, Jan 30, 2024 at 8:54 AM <[e-mail]> wrote:

> Hi Carlos,
>
> Thanks for the review.
>
> Please see one comment inline as Doc Shepherd.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Carlos Jesús Bernardos via Datatracker <[e-mail]>
> > Envoyé : mardi 30 janvier 2024 00:28
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]; tm-
> > [e-mail]
> > Objet : Intdir telechat review of draft-ietf-drip-auth-46
> >
> > Reviewer: Carlos Jesús Bernardos
> > Review result: Ready with Nits
> >
> > I am an assigned INT directorate reviewer for <draft-ietf-drip-auth>.
> > These comments were written primarily for the benefit of the Internet
> > Area Directors.
> > Document editors and shepherd(s) should treat these comments just like
> > they would treat comments from any other IETF contributors and resolve
> > them along with any other Last Call comments that have been received.
> > For more details on the INT Directorate, see
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fgroup%2Fintdir%2Fabout%2F&data=05%7C02%7Cmohamed.bo
> > ucadair%40orange.com%7C0e4b44af7875409e484d08dc2122021b%7C90c7a20af34b
> > 40bfbc48b9253b6f5d20%7C0%7C0%7C638421677139638229%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C0%7C%7C%7C&sdata=u4I%2BoRyFLPI7QXFcjjRLqyfYClefmg%2FWUVvaw6FVfck%3D
> > &reserved=0.
> >
> > Please note that this particular document is really outside of my area
> > of expertise [1].
> >
> > Based on my review, if I was on the IESG I would ballot this document
> > as NO OBJECTION.
> >
> > The only issue/comment I have is on the use of the DNS indicated in
> > the
> > document:
> >
> >    An Observer SHOULD query DNS for the UA's HI.  If not available it
> >    may have been revoked.  Note that accurate revocation status is a
> >    DIME inquiry; DNS non-response is a hint that a DET is expired or
> >    revoked.  It MAY be retrieved from a local cache, if present.  The
> >    local cache is typically populated by DNS lookups and/or by
> > received
> >    Broadcast Endorsements (Section 3.1.2).
> >
> > I think additional details would be helpful on the assumptions of the
> > DNS security mechanisms that are assumed are in place for this to work
> > (or to make this not subject of attacks).
>
> [Med] There is this text early in the document:
>
>    Like most aviation matters, the overall objectives here are security
>    and ultimately safety oriented.  Since DRIP depends on DNS for some
>    of its functions, DRIP usage of DNS needs to be protected in line
>    with best security practices.  Many participating nodes will have
>    limited local processing power and/or poor, low bandwidth QoS paths.
>    Appropriate and feasible security techniques will be highly UAS and
>    Observer situation dependent.  Therefore specification of particular
>    DNS security options, transports, etc. is outside the scope of this
>    document.
>
> >
> > The following are minor issues (typos, misspelling, minor text
> > improvements) with the document:
> >
> > - Expand DRIP in the introduction (it is done in the abstract, but I
> > think it improves readability if done also the first time the term is
> > used in the main body of the document).
> >
> > Thanks,
> >
> > Carlos
> >
> > [1] I should have probably realized this when assigning this document
> > to myself for review, thus I owe another apology.
> >
>
>
> ____________________________________________________________________________________________________________
> 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.
>
>