Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-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-iot-dns-considerations/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Chris Wood for the SECDIR review. Thank you for addressing my DISCUSS feedback and select COMMENT. ** Section 4.1 The current firmware model of the device is sometimes provided and then the authoritative server provides a determination if a new version is required and, if so, what version. What’s the authoritative server in this model? Is it the “vendor system” mentioned in the previous sentence? ** Section 5. What is the actionable BCP or design guidance from this section? ** Section 6. The difficult part is determining what to put into the MUD file itself. There are currently tools that help with the definition and analysis of MUD files, see [mudmaker]. The remaining difficulty is now the actual list of expected connections to put in the MUD file. An IoT manufacturer must now spend some time reviewing the network communications by their device. How is this germane to MUD and DNS? ** Section 7. I found this Privacy Considerations lacking a basic explanation of the DNS-focused threat model. I think the start of that threat assessment is that “many IoT devices are automatically configured to connect to the public internet to enable automatic updates, send telemetry to the manufacturers, or enable integration with manufacturer or third-party services”. Using the tradeoff template of the security considerations in Section 8, a privacy consideration trade-off might be that “device owners/operators want to leak as little onto the internet and to the device manufacturer while still getting the functionality of the IoT device”. ** Section 7. IoT devices that reach out to the manufacturer at regular intervals to check for firmware updates are informing passive eavesdroppers of the existence of a specific manufacturer's device being present at the origin location. -- Is it common in an enterprise setting for IoT devices to be able to auto-updated themselves from firmware download off the internet? In my limited enterprise experience, other end-points and network device are typically managed. Is there some nuance that these devices can only be managed the manufacturer? -- In an enterprise setting wouldn’t it be best practice to prevent devices from beaconing out to the internet with DNS blackholing or IP address filters? ** Section 7. IoT device manufacturers are encouraged to find ways to anonymize their update queries. For instance, contracting out the update notification service to a third party that deals with a large variety of devices would provide a level of defense against passive eavesdropping. This is good advice. -- Is the DNS footprint of most IoT devices predominately queries for updates? To revisit the previous comment about the threat model, don’t some IoT devices use DNS to initiate traffic for more things than just update queries negating the benefit of a third-party update infrastructure? -- Not knowing much about this is done in production, is this realistic guidance based on current IoT manufacturer practices? Collecting less data from device owner/operators seems to be opposite of the trends I have seen. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
