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

[Roman Danyliw via Datatracker <[e-mail]>]

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?

** 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?

** 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.


----------------------------------------------------------------------
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.