Hi Roman, Thanks for the review, please see inline
On Thu, 1 Aug 2024 at 20:26, Roman Danyliw via Datatracker <[email protected]> wrote: > 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. > Agreed, we will generalize the description of TTPs and focus on the broader observation that (D)TLS protocol parameters can be leveraged to block malicious and security policy-violating traffic. > > ** 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. > Yes, I removed the word "profile" to avoid confusion. > > ** 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. > Good point, updated sections 1 and 3 to high-light the above point. > > ** 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. > Agreed, but this specification is targeted at manufacturers who support MUD and they would have security as a key criteria. They are more likely to implement frequent updates to address vulnerabilities. > > ** 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. > The impact of content inspection is discussed in the second paragraph of Section 9 (Privacy considerations) of the draft. > > ** Section 4.2. What is the (D)TLS profile information being conveyed in > this > section? > This section refers to enforcing MUD policies at both the DNS (RFC8520) and TLS levels to enhance overall security; added text for clarity. > ** 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. > Proposed text looks good, updated draft. > > ** 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. > Good point, updated draft. > > ** 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? > It is becoming common for IoT devices to have TEE, For instance, LAKE WG is discussing attestation of EDHOC peers (and it is part of the charter) . > > ** 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. > Yes, fixed. Cheers, -Tiru
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
