Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-https-notif-13: (with DISCUSS and COMMENT)

[Mahesh Jethanandani <[e-mail]>]

Hi Roman,

Sorry for taking the time to get back to this. Thanks for providing review comments. Please see inline.

> On Dec 13, 2022, at 1:14 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-https-notif-13: Discuss
> 
> 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.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** Section 6.2
> 
>       container receiver-identity {
>         if-feature receiver-identity;
>         description
>           "Maps the receiver's TLS certificate to a local identity
>            enabling access control to be applied to filter out
>            notifications that the receiver may not be authorized
>            to view.";
>         container cert-maps {
>           uses x509c2n:cert-to-name;
>           description
>             "The cert-maps container is used by a TLS-based HTTP
>              server to map the HTTPS client's presented X.509
>              certificate to a 'local' username. If no matching and
>              valid cert-to-name list entry is found, the publisher
>              MUST close the connection, and MUST NOT send any
>              notifications over it.";

> 
> The ietf-x509-cert-to-name module exposes many certificate fields.  What
> specific fields need to be matched from this module and the local identity
> value?

How about this update to the description field:

        description
          "The cert-maps container is used by a TLS-based HTTP
           server to map the HTTPS client's presented X.509
           certificate to a 'local' username. Specifically, the
           'name' field within the module is used to along with
           'specified' identity to perform the match. If no
           matching and valid cert-to-name list entry is found,
           the publisher MUST close the connection, and MUST
           NOT send any notifications over it.”;

> 
> ** Unsafe TLS configurations seem possible.
> 
> (a) Section 6.2.
>     grouping https-receiver-grouping {
>       description
>         "A grouping that may be used by other modules wishing to
>          configure HTTPS-based notifications without using RFC 8639.";
>       uses httpc:http-client-stack-grouping {
> 
> (b) Section 7
>   The YANG modules in this document make use of grouping that are
>   defined in YANG Groupings for HTTP Clients and HTTP Servers
>   [I-D.ietf-netconf-http-client-server], and A YANG Data Model for SNMP
>   Configuration [RFC7407].  Please see the Security Considerations
>   section of those documents for considerations related to sensitivity
>   and vulnerability of the data nodes defined in them.
> 
> Per (a) “grouping https-receiver-grouping” seems to reference
> draft-ietf-netconf-netconf-client-server which in turn seems to reference
> draft-ietf-netconf-tls-client-server.
> 
> Per (b), the Security Considerations for
> draft-ietf-ietf-netconf-http-client-server say none of the modules are read or
> write sensitive.  Draft-ietf-netconf-tls-client-server’s Security
> Considerations (not referenced here) do note that write access could alter the
> security policy.
> 
> Please provide a declarative caution here about writing to
> https-receiver-group.  Additionally, are any TLS parameters in
> transport/tls/tls/http/client-parameters acceptable?  Should they conform to
> draft-ietf-uta-rfc7525bis?

Ok. I have updated that paragraph as follows

OLD:

  The YANG modules in this document make use of grouping that are
  defined in YANG Groupings for HTTP Clients and HTTP Servers
  [I-D.ietf-netconf-http-client-server], and A YANG Data Model for SNMP
  Configuration [RFC7407].  Please see the Security Considerations
  section of those documents for considerations related to sensitivity
  and vulnerability of the data nodes defined in them.

NEW:

The YANG modules in this document make use of grouping that are 
defined in YANG Groupings for HTTP Clients and HTTP Servers 
[I-D.ietf-netconf-http-client-server], YANG Groupings for TLS Clients 
and TLS Servers [I-D.ietf-netconf-tls-client-server], and A YANG 
Data Model for SNMP Configuration [RFC7407]. Please see the 
Security Considerations section of those documents for considerations 
related to sensitivity and vulnerability of the data nodes defined in them. 
Additionally, the parameters defined in the tls-client-grouping in the 
ietf-tls-client module should follow the recommendations specified in 
Recommendations for Secure Use of Transport Layer Security (TLS) 
and Datagram Transport Layer Security (DTLS) [RFC9325].

> 
> ** Section 10.
>   *  The "path" node in "ietf-subscribed-notif-receivers" module can be
>      modified by a malicious user to point to an invalid URI.
> 
> It could be worse than that.  An attacker could direct the to a URL of their
> choosing which could (a) serve an exploit against a vulnerable client; or (b)
> assuming redirects are followed, track usage.

I have added text that pretty much reflects these comments.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Leif Johansson for the SECDIR review
> 
> I support Lars Eggert’s and Éric Vyncke’s related DISCUSS position.
> 
> Editorially, due to the module imports, it was difficulty to read the YANG tree
> view in Section 6.1 and reconcile it with the module in Section 6.2.

Would adding a complete tree diagram in the Appendix help?

Thanks.
> 
> 
> 


Mahesh Jethanandani
[e-mail]