Skip to main content

Last Call Review of draft-ietf-opsawg-mud-tls-10
review-ietf-opsawg-mud-tls-10-secdir-lc-dunbar-2022-11-18-00

Request Review of draft-ietf-opsawg-mud-tls-10
Requested revision 10 (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-11-07
Requested 2022-10-18
Requested by Henk Birkholz
Authors Tirumaleswar Reddy.K , Dan Wing , Blake Anderson
I-D last updated 2022-11-18
Completed reviews Dnsdir Last Call review of -13 by R. (Miek) Gieben (diff)
Opsdir Last Call review of -13 by Qin Wu (diff)
Genart Last Call review of -13 by Christer Holmberg (diff)
Secdir Last Call review of -10 by Linda Dunbar (diff)
Yangdoctors Last Call review of -10 by Xufeng Liu (diff)
Dnsdir Telechat review of -15 by R. (Miek) Gieben (diff)
Comments
This is late in the process. The shepherd pointed out that this document never experienced the yangdoctors explicit attention. Considering the extensive discussion during adoption, I think a secdir review is also warranted at this stage. As this is so late and the request time is so close to the cut-off, I put the Monday of the IETF meeting as deadline. I hope that will not cause undue inconvenience.
Assignment Reviewer Linda Dunbar
State Completed
Request Last Call review on draft-ietf-opsawg-mud-tls by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/4p1CpxBbwLrm3w2ZCXhwq5M1z4Y
Reviewed revision 10 (document currently at 18)
Result Has nits
Completed 2022-11-18
review-ietf-opsawg-mud-tls-10-secdir-lc-dunbar-2022-11-18-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

This document extends the Manufacturer Usage Description specification to
incorporate the (D)TLS profile parameters for a network security service to
identify unexpected (D)TLS usage. The document has very good description of
common malware behavior that is informative.

Questions
- Are the profile on the remote IoT device or on the network device? If the
profile is on remote IoT devices, are those attributes in the profiles attached
as metadata when requesting TLS connections? Are those attributes encrypted? -
If the Malware on IoT doesn't participate in TLS, can those MUD be used to
detect the Malware on the remote IoT devices?

- Page 6, first paragraph says:
 "malware developers will have to develop malicious agents per IoT device type,
 manufacturer and model, infect the device with the tailored malware agent and
 will have keep up with updates to the device's (D)TLS profile parameters over
 time."

Does it mean that if all the IoT devices deployed in the network register their
DeviceType/ManufacturerName/Model with the network services, then the network
services can validate the TLS requests from the IoT?

-  Section 3 last paragraph says that "compromised IoT devices are typically
used for launching DDoS attacks". Can today's TLS re-negotiation validate the
TLS requests by evaluating if the server certificates are signed by the same
certifying authorities trusted by the IoT device"?

Thank you very much,

Linda Dunbar