Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-acceptable-urls-11: Abstain
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-acceptable-urls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with many things from the SecDir review from Christian Huitema: https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-acceptable-urls-11-secdir-telechat-huitema-2024-04-02/ I think the concept of small vs big changes is problematic. There is also the issue of any lower version being seen as a roll back attack. If successfull, it would prevent an administrator to downgrade the MUD file after finding that it is preventing proper functioning. A device has a firmware version and a MUD file that belongs to that version. It seems this draft says that the MUD file can be upgraded to firmware versions it was not intended for. It seems the simple fix is to not do that. Updating a MUD file to plug a security hole seems the wrong mechanism. Instead of updating the MUD file, the firmware should be updated (and that firmware should come with a new MUD file covering that firmware version) So I am confused about the mechanim of the firmware handing a URL to the MUD manager, who then picks up the MUD file from the manufacturor. In a way, one could see this as a firmware that has a bit of external firmware hosted elsewhere. And these two can get out of sync. To me that just seems like broken firmware and building a protocol mechanism to resolve this seems the wrong way to fix this. Similarly, changing a MUD file location seems to be something that should be addressed in a firmware update - including updating the location of future firmware updates. I don't see a way for this document to resolve my issues, so instead of balloting DISCUSS, I am ABSTAINing. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
