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

[Mahesh Jethanandani <[e-mail]>]

[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 <[e-mail]> 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
[e-mail]