Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-mud-tls-15: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Christer Holmberg for the GENART review. ** Section 1. [malware] indicates that there are observable differences in how malware uses encryption compared with how non-malware uses encryption. There are several interesting findings specific to (D)TLS which were found common to malware: ... [bulleted lists of findings] The techniques, tactics, and procedures (TTPSs) described in the [malware] are from 2016, 8 years ago. Is the WG confident that these exact TTPs are still in use as described? Will this text age well and is it needed? The general observation that (D)TLS protocols parameters can be used to block malicious traffic or traffic that violates policy still stands without the specifics having to be described here. ** Section 1 If observable (D)TLS profile parameters are used, the following functions are possible which have a positive impact on the local network security: What is a “profile parameter”? How does a “profile parameter” differ from any other (D)TLS protocol parameter? Editorially, the idea of profiles hasn't been introduced yet. ** Section 1 and 3. The motivation for this work is repeated multiple times as being malware and malicious behavior. Why is more basic enforcement of policy not also part of this justification. This is hinted at by text in Section 1 about “ensur[ing] TLS certificates” are valid. Observing the network for use of legacy ciphersuite or non-conformant certificates are also common cyber hygiene use cases. ** Section 3. 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. Realizing that “IoT” can mean number of things, I am surprised by this assertion. I was under the impression that update practices vary for IoT devices and rapid deployment could NOT be assumed. Specifically, being deployed on disadvantaged networks or having inconsistent/poor long-term support from their manufacturer were among a few of the reasons why timely patching of IoT doesn’t happen. ** Section 4.1 To obtain more visibility into negotiated TLS 1.3 parameters, a middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a (D)TLS proxy for the IoT devices owned and managed by the IT team in the Enterprise network and the (D)TLS proxy must meet the security and privacy requirements of the organization. If I’m understanding correctly, the setup described above is a full terminating proxy. At that point, one could certainly look at parameters, but one could also perform full content inspection. It might be useful to mention that. I am not sure what this means relative to MUD. ** Section 4.2. What is the (D)TLS profile information being conveyed in this section? ** Section 5. The (D)TLS profile YANG module provides a method for network security services to observe the (D)TLS profile parameters in the (D)TLS handshake to permit intended use and to block malicious behavior. I’m having difficulty with the clarity of this language. How does this module provide a method to observe anything? There are no RPC here. Would it be more accurate to say: NEW This YANG module provides a means to characterize the (D)TLS traffic profile of a device. Network security services can use these profiles to permit conformant traffic or to deny traffic from devices that deviates from it. ** Section 8 Although it is challenging for a malware to mimic the TLS behavior of various IoT device types and IoT device models from several manufacturers, malicious agents have a very low probability of using the same (D)TLS profile parameters as legitimate agents on the IoT device to evade detection. Could the observation being made here be clarified? Is it saying that it is challenging to mimic TLS behavior across devices, but it could still be done by malware? If so, it would be beneficial to describe why this is generically true. Certainly, some of the profile parameters are harder to mimic (e.g., certificate-authorities), but others would not (e.g., signature-algorithm. The difficulty of replications seems tied in some part to how the profile is specified. ** Section 9 The MUD URL can be stored in Trusted Execution Environment (TEE) for secure operation, enhanced data security, and prevent exposure to unauthorized software. It is common for “IoT” to have a TEE? ** Section 9 However, the malware on the IoT device won't be able to establish a (D)TLS connection with the C&C server to reveal this information because the connection would be blocked by the network security service supporting this specification. Perhaps soften this language because while it is desired/intended for the malware to be blocked the efficacy of this signature based approached is not guaranteed. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
