Hi Tiru,
Please see one comment inline.
Cheers,
Med
De : tirumal reddy <kondtir@xxxxxxxxx>
Envoyé : dimanche 7 juillet 2024 07:24
À : Qin Wu <bill.wu@xxxxxxxxxx>
Cc : ops-dir@xxxxxxxx; draft-ietf-opsawg-mud-tls.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx
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@xxxxxxxx> 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
