[Adding the IESG, the WG back on the thread, and changing the title to the original thread]
> On Apr 12, 2024, at 8:32 AM, Eliot Lear <l...@cisco.com> wrote: > > Hi Paul, > > I’d like to step through you abstain with you. I think there are some > misunderstandings about what is being proposed by this work. At a top level, > I hope you have had time to review Christian’s later comments as to how > Michael addressed his concerns. I also refer you to my and Michael’s > response to Deb. > > Let’s begin with this: >> 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. > > I don’t quite think that is what the draft is intended to say. What it’s > trying to say is that there are some corner cases that have to be addressed, > and that things are a bit nuanced. So for instance… > > Many firmware upgrades won’t involve MUD file changes because they’re just > bug fixes. > Sometimes new services can added such that there is no harm in the MUD file > expanding access. A good example might be if a service URL is being added > for firmware new versions. > Sometimes such an expansion is unsafe, and so a separate MUD file is needed. > The MUD manager needs to take note of that. Sections 5.1 and 5.2 work > through that aspect. > >> 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) > > > That’s not really what this draft is about. That’s more a core aspect of RFC > 8520. Of course you want the manufacturer to update firmware. But you might > also take a secondary service of MUD files from a security service provider > that further restricts access for particular devices, especially when the > manufacturer doesn’t update the firmware (this will happen- it’s probably > happened to your television, as it has mine!). > >> 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. > > I’m not sure I understand your concern. Could you give an example? > > Thanks, > > Eliot Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
