Hi Ben,
I re-looked into the discussion in the TLS WG mailing list and we have addressed all the comments raised by the WG members.
The issues raised by the TLS WG and addressed in the draft are:
(a) We added Section 6 to explain the rules to processing the MUD (D)TLS rules to handle ossification and updated Section 10 to enable faster update to the YANG module.
(b) Updates to the draft that the YANG module must not include GREASE values (see Section 5).
(c) Privacy issues related to not revealing the MUD URL to an attacker is discussed in Section 9.
Please let us know if you see any other pending issues.
Cheers,
-Tiru
I re-looked into the discussion in the TLS WG mailing list and we have addressed all the comments raised by the WG members.
The issues raised by the TLS WG and addressed in the draft are:
(a) We added Section 6 to explain the rules to processing the MUD (D)TLS rules to handle ossification and updated Section 10 to enable faster update to the YANG module.
(b) Updates to the draft that the YANG module must not include GREASE values (see Section 5).
(c) Privacy issues related to not revealing the MUD URL to an attacker is discussed in Section 9.
Please let us know if you see any other pending issues.
Cheers,
-Tiru
On Fri, 6 Jan 2023 at 21:43, Ben Schwartz <bemasc@xxxxxxxxxx> wrote:
Since this happened to cross my inbox, I want to reiterate that, in my view, this document has not been properly reviewed by the TLS WG. As the shepherd's writeup notes, previous reviews in the TLS group raised some significant concerns about whether this draft's approach is advisable.I would encourage the responsible AD(s) to make sure that this document has strong consensus support from the TLS WG before proceeding.On Fri, Nov 18, 2022 at 12:29 PM Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Linda Dunbar
Review result: Has Nits
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
_______________________________________________
secdir mailing list
secdir@xxxxxxxx
https://www.ietf.org/mailman/listinfo/secdir
wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
