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? 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. 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. 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. 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? 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. 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 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. 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
