Mahesh Jethanandani has entered the following ballot position for draft-ietf-opsawg-mud-tls-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5.1, paragraph 1 > This document augments the "ietf-acl" ACL YANG module defined in > [RFC8519] for signaling the IoT device (D)TLS profile. This document > defines the YANG module "ietf-acl-tls". The meaning of the symbols > in the YANG tree diagram are defined in [RFC8340] and it has the > following tree structure: I am curious about the choice of augmenting the ACL model to add this profile, instead of say using the (D)TLS model and using software to match the fields in the packet. What aspect of the ACL capability is used to create the match such that the packets land up where they should? For example, how is a leaf-list of certificate-authorities, which I understand to be strings, programmed in the ACL to come up with a matching rule? What happens if the order of the certificate-authorities in the packet is different from the way it has been programmed in hardware? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 8, paragraph 1 > Security considerations in [RFC8520] need to be taken into > consideration. The middlebox must adhere to the invariants discussed > in Section 9.3 of [RFC8446] to act as a compliant proxy. Please use the latest template from rfc8407-bis (draft-boucadair-netmod-rfc8407bis-02), Section 3.7.1, instead of RFC8407, to fill this section, and identify nodes that have vulnerabilities. Section 8.2, paragraph 5 > All the writable data nodes defined by this module may be considered > sensitive or vulnerable in some network environments. For instance, > the addition or removal of references to trusted anchors, (D)TLS > versions, cipher suites etc., can dramatically alter the implemented > security policy. For this reason, the NACM extension "default-deny- > write" has been set for all data nodes defined in this module. How about readable nodes? No reference entries found for these items, which were mentioned in the text: [RFC7469], and [draft-ietf-netconf-crypto-types]. DOWNREF [RFC8701] from this Proposed Standard to Informational RFC8701. (For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and also seems to not appear in the DOWNREF registry.) Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "man"; alternatives might be "individual", "people", "person" ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3, paragraph 2 > Malicious agents can try to use the (D)TLS profile parameters of > legitimate agents to evade detection, but it becomes a challenge to > mimic the behavior of various IoT device types and IoT device models > from several manufacturers. In other words, malware developers will > have to develop malicious agents per IoT device type, manufacturer > and model, infect the device with the tailored malware agent and will > have keep up with updates to the device's (D)TLS profile parameters > over time. Furthermore, the malware's command and control server > certificates need to be signed by the same certifying authorities > trusted by the IoT devices. Typically, IoT devices have an > infrastructure that supports a rapid deployment of updates, and > malware agents will have a near-impossible task of similarly > deploying updates and continuing to mimic the TLS behavior of the IoT > device it has infected. However, if the IoT device has reached end- > of-life and the IoT manufacturer will not issue a firmware or > software update to the Thing or will not update the MUD file, the > "is-supported" attribute defined in Section 3.6 of [RFC8520] can be > used by the MUD manager to identify the IoT manufacturer no longer > supports the device. s/the Thing/the IoT device/ The last sentence of the paragraph belongs to the next paragraph. Section 5.2, paragraph 15 > description > "The name of (D)TLS profile; space and special > characters are not allowed."; > } Tabs have been used in the model, which is throwing indentation off. Please remove all tabs from the YANG model. Uncited references: [RFC5869] and [RFC6234]. Reference [RFC6347] to RFC6347, which was obsoleted by RFC9147 (this may be on purpose). Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on purpose). Reference [RFC8152] to RFC8152, which was obsoleted by RFC9052 and RFC9053 (this may be on purpose). Reference [RFC7525] to RFC7525, which was obsoleted by RFC9325 (this may be on purpose). Document references draft-ietf-tls-esni-18, but -20 is the latest available revision. Section 1, paragraph 1 > echanisms are thus needed to help detecting malware running on an IoT device > ^^^^^^^^^ The verb "help" is used with an infinitive. Section 4.1, paragraph 2 > infrastructure to suspect anything. Thus the use of a DNS resolver not signal > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". Section 5.2, paragraph 15 > is used for version negotiation. However in (D)TLS 1.3, the "supported_vers > ^^^^^^^ A comma may be missing after the conjunctive/linking adverb "However". Section 5.3, paragraph 17 > etf-mud:mud" { description "This adds a extension for a manufacturer to indic > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 5.3, paragraph 17 > to indicate whether (D)TLS profile is is supported by a device."; leaf is-tl > ^^^^^ Possible typo: you repeated a word. Section 5.4, paragraph 10 > tor to notify the firewall is not up to date. * The two-byte values assigned > ^^^^^^^^^^ It appears that hyphens are missing in the adjective "up-to-date". Section 8.2, paragraph 2 > e Module IANA is requested to create an the initial version of the IANA-maint > ^^ Did you mean "and" or "any"? _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
