On Wed, 10 Jul 2024 at 14:10, <mohamed.boucadair@orange.com> wrote:

> Hi Tiru,
>
>
>
> Please see one comment inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* tirumal reddy <kondtir@gmail.com>
> *Envoyé :* dimanche 7 juillet 2024 07:24
> *À :* Qin Wu <bill.wu@huawei.com>
> *Cc :* ops-dir@ietf.org; draft-ietf-opsawg-mud-tls.all@ietf.org;
> last-call@ietf.org; opsawg@ietf.org
> *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 <noreply@ietf.org>
> 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.
>
>