Re: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-32.txt

Hi Tom,

Thank you for your review of the tls-client-server draft.
Please see below for my responses to your comments.

Kent

> On Jan 5, 2023, at 11:41 AM, tom petch <ietfc@btconnect.com> wrote:
> 
> Some thoughts on  -25
> 
> tcp-client tcp-server local address includes the zone as does implicitly the remote address

[this comment should be in a separate email on the tcp-client-server draft]

Nonetheless, I converted the two "inet:ip-address" to "init:ip-address-no-zone".  There's nothing I can do about the "inet:host" type referring to "inet:ip-address" (there is no "inet:host-no-zone" type, nor in the WGLC 6991-bis doc).

> The YANG modules contain two references to SOCKS documents - these need adding to the I-D References

[this comment should be in a separate email on the tcp-client-server draft]

Nonetheless, Fixed.

>     <local-address>10.20.30.40</local-address>
> this is an allocated addess - should be a documentation one

[this comment should be in a separate email on the tcp-client-server draft]

Now 192.0.2.2.

>     <local-port>7777</local-port>
> this port is allocated to cbt; not lure what the connection is with NETCONF

[this comment should be in a separate email on the tcp-client-server draft]

IDK, is there a special TCP-port set aside for RFCs?

FWIW, connection to NETCONF protocol is irrelevant.

> Security Consideration should include RFC references for TLS, SSH, as per YANG Guidelines (which opens up a can of worms)

Does the can of worms entail the fact that this is how the IESG template is written and now there are dozens of RFCs published w/o these two refs in the Security Considerations section?

> Security Considerations talks of mutual authentication which is almost always not the case for TLS.

That section (in the template) specifically regards NETCONF/TLS and RESTCONF/HTTPS and, in both cases, the protocol requires mutual auth.

> Security Considerations says that NACM default deny all has been applied to the cleartext password.  Not really.  The NACM is applied in another module which hopefully it will continue to do but I think that the dependency needs stating explicitly to save people a wild goose chase.

It is explicit, no?  Current text reads:

            Please be aware that this module uses the "key" and "private-key"
            nodes from the "ietf-crypto-types" module [I-D.ietf-netconf-crypto-types],
            where said nodes have the NACM extension "default-deny-all" set, thus
            preventing unrestricted read-access to the cleartext key values.

Kent

> 
> Tom Petch
> ________________________________________
> From: netconf <netconf-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: 12 December 2022 18:51
> To: i-d-announce@ietf.org
> Cc: netconf@ietf.org
> Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-32.txt
> 
> Tom Petch
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Configuration WG of the IETF.
> 
>        Title           : YANG Groupings for TLS Clients and TLS Servers
>        Author          : Kent Watsen
>  Filename        : draft-ietf-netconf-tls-client-server-32.txt
>  Pages           : 155
>  Date            : 2022-12-12
> 
> Abstract:
>   This document defines three YANG 1.1 modules: the first defines
>   features and groupings common to both TLS clients and TLS servers,
>   the second defines a grouping for a generic TLS client, and the third
>   defines a grouping for a generic TLS server.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>   This draft contains placeholder values that need to be replaced with
>   finalized values at the time of publication.  This note summarizes
>   all of the substitutions that are needed.  No other RFC Editor
>   instructions are specified elsewhere in this document.
> 
>   Artwork in this document contains shorthand references to drafts in
>   progress.  Please apply the following replacements:
> 
>   *  AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-
>      types
> 
>   *  BBBB --> the assigned RFC value for draft-ietf-netconf-trust-
>      anchors
> 
>   *  CCCC --> the assigned RFC value for draft-ietf-netconf-keystore
> 
>   *  DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-
>      server
> 
>   *  FFFF --> the assigned RFC value for this draft
> 
>   Artwork in this document contains placeholder values for the date of
>   publication of this draft.  Please apply the following replacement:
> 
>   *  2022-12-12 --> the publication date of this draft
>   The "Relation to other RFCs" section Section 1.1 contains the text
>   "one or more YANG modules" and, later, "modules".  This text is
>   sourced from a file in a context where it is unknown how many modules
>   a draft defines.  The text is not wrong as is, but it may be improved
>   by stating more directly how many modules are defined.
> 
>   The "Relation to other RFCs" section Section 1.1 contains a self-
>   reference to this draft, along with a corresponding Informative
>   Reference in the Appendix.
> 
>   The following Appendix section is to be removed prior to publication:
> 
>   *  Appendix B.  Change Log
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-netconf-tls-client-server-32.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-tls-client-server-32
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf