Hi Deb, Thanks for the review. Please see inline
On Sun, 4 Aug 2024 at 00:27, Deb Cooley via Datatracker <nore...@ietf.org> wrote: > Deb Cooley 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 Linda Dunbar for the secdir review of this draft. > > General comment: Personally, I think this draft needs a rewrite to > tighten and > clarify the language used. I was 'this close' to filing a discuss. > > Specific comments: > > Abstract: I thought originally that this was a profile of (D)TLS, but it > is > not. At best, I'd call this a framework to allow a manufacturer to create > a > profile. Replacing 'incorporate' with 'allow manufacturers to define' > might > make it more clear. > Thanks, updated text. > > Section 1, para 2: I share Roman's concern about the age of the > reference, and > the claims made by that reference a full 8 years later. > Yes, I responded to Roman that 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, para 2, bullet 3: I'm not sure what 'self-signed certificates > compared with typical legitimate software' means. As written it seems > like an > 'apples to oranges' comparison? Maybe the authors mean that they see more > self-signed certificates compared with CA certificates that the IOT device > trusts'? > No, we meant self-signed certificates are typically used by malware (for instance see, https://www.trendmicro.com/en_us/research/21/i/analyzing-ssl-tls-certificates-used-by-malware.html) compared to legitimate software using PKIX certificates. > > Section 1, para 3: Replace the first phrase of the first sentence with: > 'If > (D)TLS profile parameters are selected, the following...'? It needs to be > clear that this RFC is establishing a way for a profile to be defined for > both > DTLS and TLS. > Yes, replaced with 'If (D)TLS profile parameters are defined, the following...' > > Section 1, para 3, bullet 1: Please define ACL. And if it is 'access > control > list', please explain what that means in this context. [later in the > draft it > is use in a way that I'm not used to - i.e. not as a way to control > access....] > Fixed. > > Section 3: In general, a malware developer just needs a key and > certificate > signed by any of the IOT device's trusted certificate authorities (CAs). > How > hard that is depends on how many CAs the IOT device trusts. > Unlike the developers of legitimate applications, malware authors are under additional constraints such as avoiding any noticeable differences on the infected devices and the potential for take-down requests impacting their server infrastructure (e.g., CA revoking the certificate). > > Section 4: If these fields of the handshake are in the clear, then it is > possible that the malware developer can see them just as easily as the > middlebox. It is always good practice for a server to reject connection > attempts that don't follow the installed configuration. I'm not sure what > the > value is of a middlebox that is not a (D)TLS proxy in this case. > It is possible to identify malware without having to act as a proxy, the results with Google Home and several malware families were presented in T2TRG, please see https://datatracker.ietf.org/meeting/interim-2020-t2trg-01/materials/slides-interim-2020-t2trg-01-sessa- mud-dtls-profiles-for-iot-devices-00.pdf for details. > > Section 5: The YANG modules establish the framework for a manufacturer to > design and deploy a (D)TLS profile. The YANG module itself makes no > selections. It is just a laundry list of options that can be chosen. > It provides a comprehensive and flexible framework for manufacturers to define (D)TLS profiles. For instance, see the white paper (Traffic Analytics <https://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/enterprise-network-security/nb-09-encrytd-traf-anlytcs-wp-cte-en.html>) on encrypted traffic analytics, which lists various TLS parameters used to identify malware. > > Section 8, para 2: These are statements made by the authors, is there a > reference or evidence to back up that claim? > Yes, please see my above response and TLS profile parameters are already leveraged by network security vendors to identify malware (for example, see https://secure.cisco.com/secure-firewall/docs/encrypted-visibility-engine). Cheers, -Tiru > > Section 8.1-8.3: As I've commented in the past, these statements are not > actually security considerations. Given that it has apparently been agreed > that the statements are sufficient, no change is required.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
