Hi Qin, Thanks for the review. Please see inline
On Wed, 28 Feb 2024 at 15:33, Qin Wu via Datatracker <[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. > > 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. -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. >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
