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. 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. 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'? 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. 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....] 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. 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. 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. Section 8, para 2: These are statements made by the authors, is there a reference or evidence to back up that claim? 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
