Hi Tirumal, Thanks for your responses. See inline for some follow-up comments.
> On Aug 7, 2024, at 7:17 AM, tirumal reddy <kond...@gmail.com> wrote: > > Hi Mahesh, > > Thanks for the review. Please see inline > > On Tue, 6 Aug 2024 at 04:38, Mahesh Jethanandani via Datatracker > <nore...@ietf.org <mailto:nore...@ietf.org>> wrote: > 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/ > <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/ > <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 ? > > In the TLS handshake, the client and server exchange certificates once, and > each certificate is signed by a single CA. The TLS peer will have to > validate the end-entity certificate to the last intermediate CA certificate > listed in the chain, which requires the correct order of the certificate > chain to be maintained. Regarding the ACLs, the proposed technique is > designed to complement existing Layer 3, Layer 4, and DNS-based filtering by > MUD using ACLs. > > I am not a TLS expert, so pardon me if some of these questions are dumb questions. MUD has used ACLs in the past to create match filters. But for anything related to strings, e.g. URIs or hostnames, it has generally tended to do a wildcard match. E.g. if the MUD rule is example.com <http://flobbidy.example.com/>, then any URL flobbidy.example.com <http://flobbidy.example.com/> would match. Those URLs are static and known at the time of setup. But I assume that in this case we are talking about something more dynamic - a certificate chain, which is learnt as part of the TLS handshake, even as they are signed by a single CA. And once that session closes, that certificate chain goes away, or is no longer applicable. You say that the TLS peer will have to be validate the end-entity certificate to the last intermediate CA certificate listed in the chain. And you want to do it by specifying a ACL match rule for the leaf-list of certificate-authorities. My question therefore is, when an end-entity certificate needs to be validated, are these certificate chains known in advance, such that they can be programmed into the ACL? If not, and if they are being learnt as part of TLS handshake, how are they part of a pre-configured ACL rule? Thanks. > > > ---------------------------------------------------------------------- > 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. > > Updated. > > > 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? > > Good point, updated draft. > > No reference entries found for these items, which were mentioned in the text: > [RFC7469], and [draft-ietf-netconf-crypto-types]. > > RFC7469 is referred to indicate how the public key would be pinned and > trust-anchor-cert-cms defined in draft-ietf-netconf-crypto-types is leveraged > by the ""ietf-acl-tls" Module. Please clarify on the reference entries you > are looking for. > > > 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.) > > RFC8701 is already referenced by other proposed standards like RFC9420 > > > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-editor.org/part2/#inclusive_language > <https://www.rfc-editor.org/part2/#inclusive_language> for background and more > guidance: > > * Term "man"; alternatives might be "individual", "people", "person" > > The term is widely used by several recent RFCs including TLS 1.3 (RFC8446). > > > ------------------------------------------------------------------------------- > 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 > <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"? > > Thanks, fixed nits. > > Cheers, > -Tiru Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
