inline below w/ [DC].... I'd like to see the revised draft, once it is published (recognizing that I'm not blocking publication).
Deb On Mon, Aug 5, 2024 at 6:58 AM tirumal reddy <kond...@gmail.com> wrote: > 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. > [DC} will you make a change in the text? PKIX certificates should be called 'certificates from a CA trusted by the device' to be clear. (there are many ways to say this, neither PKIX or X.509 are specific). > > >> >> 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). > [DC] surely this is true no matter what key/certificate they use? A legit CA won't revoke a certificate unless there is reporting - I'm not sure what reporting would have to happen for a CA to revoke a malware authors' certificate. And then revocation would have to be checked, which honestly doesn't happen often. > > >> >> 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. > [DC] this is fine, but it isn't a profile as it is published. > >> 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 > ). > [DC] will you reference this? > > 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
