[OPSAWG] Paul Wouters' Abstain on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

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.