Hi Tiru, Please see one comment inline.
Cheers, Med De : tirumal reddy <[email protected]> Envoyé : dimanche 7 juillet 2024 07:24 À : Qin Wu <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : [Last-Call] Re: Opsdir last call review of draft-ietf-opsawg-mud-tls-13 Hi Qin, Thanks for the review. Please see inline On Wed, 28 Feb 2024 at 15:33, Qin Wu via Datatracker <[email protected]<mailto:[email protected]>> wrote: Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines 3 YANG modules and specifies TLS profile for IoT device. This TLS or DTLS profile can be used to detect unexpected TLS usage and prevent malware download, block access to malicious domains, etc. This document is on the right track and almost ready for publication. However I have a few comments, especially to security section and IANA section, on the latest version v-13: Major issues: None Minor issues 1. Abstract said: " This memo extends the Manufacturer Usage Description (MUD) specification to incorporate (D)TLS profile parameters. " This draft defines 3 YANG data modules, do you think all these 3 YANG modules extend MUD specification? The YANG module defined in Section 5.4 of the draft extends the MUD specification. 2. Section 5.3 IANA (D)TLS profile YANG Module Section 5.3 seems a little bit overdesign, see the section 2 of RFC7224, I think the first 5 paragraphs in section 5.3 can be moved or consolidated into IANA subsection for specific IANA maintained module. IANA subsection is referencing section 5.3, please see https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-13.html#section-10.1 3. Section 6 Processing of the MUD (D)TLS Profile As for processing of the MUD TLS profile, I am wondering when the MUL DTLS profile is not compliant, e.g., some TLS parameters are not defined in the MUD TLS profile, do we need to define Error handling and standard Error code, report specific error code to the management system? If it is not in the scope, I think it will be nice to call out explicitly. Otherwise it seems like a not complete solution. It is discussed in Section 6 that an alert would be triggered. 4. Section 6 said: " If the (D)TLS parameter observed in a (D)TLS session is not specified in the MUD (D)TLS profile and the (D)TLS parameter is not recognized by the firewall, it can ignore the unrecognized parameter and the correct behavior is not to block the (D)TLS session. " Regarding DTLS parameters not recognized by the firewall, I am wondering there still is potential security risk. Is there needed to report these unrecognized parameters associated with some security context information to the management system for further investigation. This rule ensures that the network security service will ignore the GREASE values advertised by TLS peers and interoperate with the implementations advertising GREASE values. GREASE is introduced to generate random extensions to check and prevent extensibility failures in the TLS, see https://www.rfc-editor.org/rfc/rfc8701.html for more details. 5. Section 6 also said: " * Deployments update at different rates, so an updated MUD (D)TLS profile may support newer parameters. If the firewall does not recognize the newer parameters, an alert should be triggered to the firewall vendor and the IoT device owner or administrator. " I believe this alert is necessary for security protection or further investigation, do you think the same alert should be used to remind IoT Device owner or administrators to update device software or firmware? Good point, Section 6 is updated in the latest version of the draft with the following change: If the MUD (D)TLS profile includes any parameters that are susceptible to attacks (e.g., weaker cryptographic parameters), an alert should be triggered to the firewall vendor and the IoT device owner or administrator. 6 Section 8 Security Section This draft defines three YANG modules, ietf-acl-tls.yang, iana-tls-profile.yang, ietf-mud-tls. ietf-acl-tls.yang is extended from ACL module defined in RFC8519, iana-tls-profile.yang is standalone module, the third module draft-mud-tls is extended from MUD module defined in RFC8520. Following the structure of section 5 of draft-ietf-netconf-ssh-client-server, I think security consideration should be specified for each YANG data module. The YANG modules are not intended to be accessed via NETCONF. The security considerations mentioned in RFC8407 are not applicable in this case. [Med] I think Qin has a point here. FWIW, the only exceptions to not use the template as called in draft-ietf-netmod-rfc8407bis are: Unless the modules comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]), the security section MUST be patterned after the latest approved template I know that the base mud spec does not follow the template (it points to 8519, however), but the reasoning for not following the template is not valid IMO. I'd like to clarify that the template is not specific to NETCONF. As a general note, YANG (not only mud models) can be used independent of NETCONF. I suggest you look at the latest version at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-14#name-security-considerations-sect and pick parts that apply to your modules. Secondly, since the first YANG module ietf-acl-tls.yang is extended from ACL YANG data module defined in RFC85219 therefore I still think security considerations mentioned in Section 3.7 of [RFC8407]still apply. Please follow example in section 5.7 of draft-ietf-netconf-ssh-client-server. 7. Section 8 Security consideration s/anomaly detection/network anomaly detection Fixed in the latest version. 8. Section 10 IANA consideration Similarly, since this draft defines three YANG data modules, I think IANA consideration should be specified for each YANG data module. You can follow the example in section 6.3, 6.4 of draft-ietf-netconf-ssh-client-server. I don't see any such considerations discussed in the base MUD specification, see https://datatracker.ietf.org/doc/rfc8520/. MUD YANG Modules are not supposed to be used via RESTCONF or NETCONF. [Med] but still used for "network management" :-) -Tiru 9. Section 10 IANA consideration said: " IANA is requested to create an the initial version of the IANA- maintained YANG Module called "iana-tls-profile", based on the contents of Section 5.3, which will allow for new (D)TLS parameters and (D)TLS versions to be added. IANA is requested to add this note: " Please follow the template defined in Section 4.30.3.1 of [I-D.ietf-netmod-rfc8407bis] for IANA maintained YANG modules and consolidate the text described in section 5.3. See example in section 6.4 of draft-ietf-netconf-ssh-client-server. ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
