Re-, Your initial suggested text had “require the use” which is IMO different from the initial intent.
Anyway, thanks for clarifying. I updated the text to expand the protocols we are talking about (and also the template): https://github.com/netmod-wg/enhanced-acl-netmod/commit/86da0786878ddf2b899ba3bc0ce88c97b8230bc3 Cheers, Med De : Deb Cooley <[email protected]> Envoyé : mardi 1 avril 2025 12:54 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Deb Cooley's No Objection on draft-ietf-netmod-acl-extensions-15: (with COMMENT) On just this particular point: 'Section 5, para 2: Please replace the second (and last sentence) with "The YANG-based management protocols require the use of a secure transport layer such as SSH [RFC4252], TLS [RFC8446], or QUIC [RFC9000]. The YANG-based management protocols also require mutual authentication." ' The old text is: "These protocols have to use a secure transport layer (e.g., SSH [RFC4252<https://www.ietf.org/archive/id/draft-ietf-netmod-acl-extensions-15.html#RFC4252>], TLS [RFC8446<https://www.ietf.org/archive/id/draft-ietf-netmod-acl-extensions-15.html#RFC8446>], and QUIC [RFC9000<https://www.ietf.org/archive/id/draft-ietf-netmod-acl-extensions-15.html#RFC9000>]) and have to use mutual authentication." Where 'these protocols' are 'YANG-based management protocols' as specified in the previous sentence. My point is that the second half of that original sentence is confusing. What exactly has to use 'mutual authentication'? Presumably it is the Yang-based management protocols', but it gets lost in the long parenthetical. To be clearer for the reader/implementer/operator, please separate into two sentences where the requirement is to 1. use a 'secure transport layer', and 2. use 'mutual authentication'. I introduced no new ideas or requirements in my proposed change. No where did I mention MTI. One small note on the adverbs: The adverbs 'reasonably', 'particularly', and even 'especially' imply gradients that don't really exist. Either data is sensitive or it is not, communication can be disrupted or it can not, etc. Deb On Tue, Apr 1, 2025 at 1:59 AM <[email protected]<mailto:[email protected]>> wrote: Hi Deb, Thanks for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Deb Cooley via Datatracker <[email protected]<mailto:[email protected]>> > Envoyé : mardi 1 avril 2025 01:05 > À : The IESG <[email protected]<mailto:[email protected]>> > Cc : > [email protected]<mailto:[email protected]>; > netmod- > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]> > Objet : Deb Cooley's No Objection on draft-ietf-netmod-acl- > extensions-15: (with COMMENT) > > > Deb Cooley has entered the following ballot position for > draft-ietf-netmod-acl-extensions-15: No Objection > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > > ------------------------------------------------------------------ > COMMENT: > ------------------------------------------------------------------ > > Thank you to Sean Turner and Linda Dunbar for their secdir > reviews: > > Section 5, para 2: Please replace the second (and last sentence) > with "The > YANG-based management protocols require the use of a secure [Med] The rationale is to focus on the actual use rather than reasoning about MTI. I will keep the current wording. As a side note, YANG data can be transported over other protocols (including those defined outside the IETF) and I don't think we can make a claim about what they require. > transport layer > such as SSH [RFC4252], TLS [RFC8446], or QUIC [RFC9000]. The > YANG-based > management protocols also require mutual authentication." [Med] Idem as above. We spent some cycles on this in the WG and decided to emphasis on the actual use, which is more important from a deployment standpoint. Will keep the current wording. Thanks > > Section 5, para 4: Please define 'reasonably sensitive or > vulnerable' and [Med] This is coming from the template ;-) More seriously, the intent here is to remind that all configurable nodes may be misused. There might be some cases such as "description" or "comment" like data nodes, but even those, they are used sometimes by operators to enclose operational data (and thus case feed other misuses). We don't want the authors of YANG documents to list every data node in the security section, but only focus on those that particularly sensitive. > 'particular sensitivities/vulnerabilities. Alternatively, delete > the words > 'reasonably' and 'particular'. [Med] "Particular" is used on purpose as we focus on those that may lead to major disruption. FWIW, this mirrors the this part of RFC8407: * Writable data nodes that could be **especially** disruptive if abused MUST be explicitly listed by name, and the associated security risks MUST be explained. > > Section 5, para 5: Perhaps the second to last sentence should say > 'The former > may result in the exposure of sensitive data, or compromise a > device. > [Med] "Exposure of sensitive data" is not a vulnerability of a writeable parameter. The OLD is more accurate as this is about issues with writeable data node, not readable ones. I will keep the current text as it is. Thanks. > Section 5, para 7: Please delete the word 'particular'. [Med] Idem as above. This is important as we don't list every node, but only those that matches this part from 8407: "Readable data nodes that contain **especially** sensitive information or that raise significant privacy concerns MUST be explicitly listed by name, and the reasons for the sensitivity/privacy concerns MUST be explained." ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
