Hi Mahesh, Please see inline
On Thu, 8 Aug 2024 at 10:29, Mahesh Jethanandani <mjethanand...@gmail.com> wrote: > 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> 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/ >> >> 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 ? >> > > 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 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? > Yes, the endpoint would have the CAs pre-configured on it to validate the certificate and the information would be included in the pre-configured ACL. Cheers, -Tiru > 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 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), 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
