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

[Mahesh Jethanandani <[e-mail]>]

Hi Roman,

We just posted a -14 version of the draft that incorporates the suggested text below. Let us know if it addresses your concerns.

Thanks.

> On Nov 21, 2023, at 6:37 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
> 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] <mailto:[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/ <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/ <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] <mailto:[e-mail]>

Mahesh Jethanandani
[e-mail]