[netmod] Re: AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review

[Mahesh Jethanandani <[e-mail]>]

Hi Med,

Thanks for making the updates. One edit I would make is the link to the wiki page where the security considerations reside. It is:

https://wiki.ietf.org/en/group/ops/yang-security-guidelines

Once it is finalized here, I will ask the secretariat to update the template at that link.

Thanks.

> On Sep 18, 2024, at 7:59 AM, [e-mail] wrote:
> 
> Hi Kent,
>  
> Thanks for the follow-up.
>  
> I went with many of your proposals. For “have to use/have mandatory/MUST use”, I went for “have to use” for now. The use of normative language may be questionable as this is more about use, less of an interop matter. 
>  
> A full diff to track changes can be seen here: https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/sec-comment-from-Kent/draft-ietf-netmod-rfc8407bis.txt <https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/sec-comment-from-Kent/draft-ietf-netmod-rfc8407bis.txt>.
>  
> Let me know if there are other occurrences that I missed where we need to follow “modeled after” approach. Thank you.
>  
> Cheers,
> Med
>  
> De : Kent Watsen <[e-mail]> 
> Envoyé : jeudi 12 septembre 2024 18:02
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : Mahesh Jethanandani <[e-mail]>; [e-mail]
> Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review
>  
> 
> Hi Med,
>  
> Sorry this is taking so long, but we’re getting there!  ;)
>  
>  
> The reference of QUIC is to the protocol, RFC 9000, not NETCONF over QUIC, an I-D as you note; just as the reference is to SSH protocol, RFC 4252, not NETCONF over SSH, RFC 6242.
> [Med] I understand the intent is to cite the transport themselves, but the text refers to MTI of these “YANG-based management protocols”. I don’t think we can make any claim about QUIC here as we don’t have an authoritative spec for that. If we want to cite QUIC, some further tweaking to the text is needed, IMO.
>  
> RESTCONF already supports QUIC. 
> [Med] Yes, RESTCONF does not  require a specific version of HTTP but still TLS is what is indicated as MTI for RC per rfc8040#section-2.1.
>  
> I was thinking about this nuance too.  QUIC uses TLS, so I think rfc8040#section-2.1 is still satisfied.  That said, the NETCONF WG will be working on a RESTCONF-next version, for which it would be easy to add some clarifying text - agreed?   I just added this (https://github.com/netconf-wg/restconf-next/issues/19 <https://github.com/netconf-wg/restconf-next/issues/19>) - good for now?
>  
> No transport-binding document will be written to enable QUIC for RC. 
> [Med] Isn’t rfc9114 that is applicable for RC, rather than 9000?
>  
> RFC 9112: HTTP/1.1 (i.e., TCP-or-TLS over TCP)
> RFC 9113: HTTP/2 (i.e., TLS over TCP)
> RFC 9114: HTTP/3 (i.e., QUIC, i.e., TLS over UDP)
>  
> If we ref 9114, then we’d have to ref the others also, which isn’t what we want.  This is why 9000 is refed - makes sense?
>  
> 
> 
> [mj] Why do you say that? The statement says the protocols have mandatory-to-implement …
> [Med] Having an MTI does not mean that MTI is actually used/enabled.
>  
> Touché  :)
>  
> One could process “implement” to be at the runtime-level or code-level.  I meant the former, and see that you’re interpreting the later, which is fair. 
>  
> First, I wonder if there isn’t a formal definition for MTI that disambiguates the two cases.  Looking, I see MTI used in the context of algorithms, which lends itself to the “code level” interpretation.  Fine. 
>  
> [Med] Thanks
>  
> Then either s/implement/use/  or  s/-to-implement// ?
> [Med] « have to use » would be better, IMO.
>  
> Hmmm, so this?
>  
> These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and have to use mutual authentication.
>  
> vs
>  
> These protocols have mandatory to use secure transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and mandatory to use mutual authentication.
>  
> Vs
>  
> These protocols have mandatory secure transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and mandatory mutual authentication.
> 
> 
> Of the three, I like the last one most, but like the first one (yours) next.   I like the last one since the statement seems stronger.  One idea might be this:
> 
> 
> These protocols MUST use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and MUST use mutual authentication.
> 
> 
> But I don’t think RFC2119 language should be in the Security Considerations section.
>  
> Thoughts?
>  
> 
> 
> This section is modeled after the template described in Section 3.7 of [RFCAAAA].
>  
> This first line wasn’t picked up.  Note that the word “modeled” gives an authors a little flexibility, as is needed sometimes.  
>  
> To point, the RFC Editor takes the words literally and raise issues when things aren’t exactly same…until this word was changed. 
>  
> Honestly, the same should be done to all of the templates defined in the document.  
>  
> [Med] This is fair. Please see: https://github.com/netmod-wg/rfc8407bis/commit/972970ce16c050d8420f50f07637f4e00770cdd5 <https://github.com/netmod-wg/rfc8407bis/commit/972970ce16c050d8420f50f07637f4e00770cdd5>
>  
> Thanks, both for accommodating and the link.
>  
> Looking at the PR, it is only for this template.  Do you not agree that “modeled after” is good for all of the templates?
>  
>  
> 
> 
> The "<module-name>" YANG module defines a data model that is designed to be accessed via YANG-
>  
> IIRC, you use different words than “data model”.   I’m trying to use sufficiently ambiguous language that includes also modules that only define identities, or only enumerations, or only typedefs, etc.  
>  
> I was going to write “data model, or parts of data models,” but it seemed unnecessarily wordy and obscures the main point of the sentence. 
>  
> I don’t deny that my text could be improved, but your take didn’t seem right either. 
>  
> Can you reply to this?
>  
> So we have:
>  
> The "<module-name>" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, 
>  
> vs.
>  
> The "<module-name>" YANG module defines a schema for data that is designed to be accessed via YANG-based management protocols,
>  
>  
> 
> 
> FWIW, I only know about your changes to my text because I received GitHub notifications.  Was a link for the PR sent?  In any case, it would’ve been nice if you’d stated that changes had been made, rather than me having to discover them on my own. 
>  
> [Med] I didn’t share the PR because that wasn’t ready yet and I was waiting for the discussion to converge to have something I’m more happy with it. Now that you are on it, feel free to propose your edits directly there :-) Thanks.
>  
> I’m unsure what you mean, but I don’t want to submit PRs and, honestly, I don’t want to look at PRs.  I want the full conversation to be on the list. 
>  
>  
> Kent // contributor
>  
>  
> ____________________________________________________________________________________________________________
> 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.