Hi Éric, Thanks for the review. Please see inline
On Mon, 5 Aug 2024 at 14:37, Éric Vyncke via Datatracker <nore...@ietf.org> wrote: > Éric Vyncke 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: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-tls-15 > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and one nit. > > Special thanks to Thomas Fossati for the 18-month old shepherd's detailed > write-up including the WG consensus and a *very light* justification of the > intended status. > > Other thanks to Miek Gieben, the Internet directorate reviewer, please > consider > this int-dir review: > > https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-tls-15-dnsdir-telechat-gieben-2024-07-27/ > (alas there is still no mention to RFC 7858 in this revision even after > Tiru's > 2024-07-29 email) > It is updated in the Github repo https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-16.txt. We plan to publish a revised draft later this week. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS (non-blocking) > > ## Section 12.2 > > Please fix this, there are 2 normative references listed for RFC 6234 & > 5869 > that are not used at all, i.e., remove all unused references (per idnits > tool). > Thanks, I removed those references. > > ## Section 1 > > Like observed by Roman, using an 8-year old reference as the foundation of > this > document may indicate that this document may be useless in 2024. > 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. > > In `Specifically, malware may not use the DoH server provided by the local > network` please add references to ADD RFC. > Fixed. > > Humm, I wonder why there is "mud" in the I-D title if the document contains > `This is superior to the layers 3 and 4 ACLs of Manufacturer Usage > Description > Specification (MUD)` ;-) > The document builds upon the MUD framework by extending it to include (D)TLS profile parameters. It is only meant to highlight the additional security measures provided. I added the following text for clarity: The goal is to enhance and complement the existing MUD specifications, rather than to undermine them. > > ## Section 3 > > "middlebox" is used but not specified in this document, suggest using the > right > MUD terminology. The ambiguous "middlebox" also appears in other sections. > I added the term for "middlebox". A middlebox that interacts with TLS traffic can either act as a TLS proxy, intercepting and decrypting the traffic for inspection, or inspect the traffic between TLS peers without terminating the TLS session. > > Is ` end-of-life of a device` linked to ` IoT manufacturer no longer > supports > the device`, I guess so but this is not clear at all. > Yes, updated text for clarity. > > Please add a reference to "Slowloris". > Done. > > ## Section 5.2 > > As some IoT devices won't ever be updated, should the YANG module also > support > *obsoleted* TLS versions ? A very contentious decision of course but I > would > prefer to support it than ignoring old devices. > Networks and IoT devices that support MUD would consider security a key criteria and they would most likely avoid using obsoleted TLS versions. > > # NITS (non-blocking / cosmetic) > > ## Section 7 > > The example includes `2019-18-06T` could it be refreshed to 2024 ? > Yes, fixed. Cheers, -Tiru
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
