On Wed, 10 Jul 2024 at 14:10, <[email protected]> wrote: > 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]> > 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 > <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-14#name-security-considerations-sect> > and pick parts that apply to your modules.* >
Got it, Thanks. We will update the draft. Cheers, -Tiru > > > > 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]
