On Wed, 7 Aug 2024 at 15:19, Deb Cooley <debcool...@gmail.com> wrote:
> inline below w/ [DC].... I'd like to see the revised draft, once it is > published (recognizing that I'm not blocking publication). > We published a revised draft to address comments from the ISEG review. > > 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). > Thanks, Fixed. > > >> >>> >>> 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. > Yes, CA typically revokes a certificate only upon receiving a report of misuse. OSCP stapling would solve the problem of checking whether the certificate is revoked. > >> >>> >>> 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? > Done. -Tiru > > >> 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
