Thanks for addressing these issues, Tiru. To confirm that this document now reflects IETF consensus, I think it would be logical to send it to the TLS WG (noting those changes) and confirm that it now has consensus there.
On Mon, Jan 9, 2023 at 1:07 AM tirumal reddy <kond...@gmail.com> wrote: > 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 > > On Fri, 6 Jan 2023 at 21:43, Ben Schwartz <bem...@google.com> 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 < >> nore...@ietf.org> 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 >>> sec...@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview >>> >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
