[netmod] Re: Deb Cooley's No Objection on draft-ietf-netmod-acl-extensions-15: (with COMMENT)

[Deb Cooley <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Deb,
>
> Thanks for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Deb Cooley via Datatracker <[e-mail]>
> > Envoyé : mardi 1 avril 2025 01:05
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; netmod-
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > 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.
>
>