Re: [OPSAWG] Last Call Review of draft-ietf-opsawg-mud-acceptable-urls-10

[Christian Huitema <[e-mail]>]

On 2/28/2024 12:04 AM, Eliot Lear wrote:
> Hi Christian and thanks for another good read of another MUD document. 
> You've largely summarized the situation well, taking into account what 
> RFC 8520 states.
> 
> I want to note that your comments about detached signatures were 
> specified in RFC 8520.  This draft tries to work within that framework 
> without updating the format.  Signatures were detached for a particular 
> reason- readability during the early stages of this technology's 
> deployment without the need to apply canonicalization rules that would 
> obscure the text.  The issues this document raises are not specifically 
> around the fact that the signature is detached, but that the underlying 
> MUD URL could change.  There may indeed be threats involved with using 
> detached signatures, but I would hold that work for an overall MUD 
> revision, which I think should happen at some point soon.  This draft is 
> considerably more tightly scoped.

Reading the document, I could not figure out how to proceed with that 
signature verification. A pointer to the proper doc would be nice.

> 
> Regarding this text, first I note editorially that we should separate 
> the the file structure change from the rest of the Section 5 chapeau 
> text.  I will work with Michael on that.
> 
>> This "common prefix" rule for "small changes" is light weight but has an
>> obvious hole. Suppose that a manufacturer has first published a rather 
>> loose
>> rule in "https://example.com/widget-x/revision1.html  
>> <https://example.com/widget-x/revision1.html>", and then upgraded it to
>> a stricter rule in "https://example.com/widget-x/revision2.html  
>> <https://example.com/widget-x/revision2.html>". The common
>> prefix rule will not prevent the virus from "rolling back" to 
>> revision1. A
>> simple solution would be for the manufacturer to update the MUD FILE 
>> served at
>> the old MUD URL so that it point to the new MUD URL -- which is 
>> exactly what
>> the manufacturer would do under the "big change" rules.
> 
> I would note that the risk here is when revision1 contains rules that 
> allow for broader access *beyond *the domain of the manufacturer or when 
> a portion of the manufacturer's infrastructure itself has been 
> compromised.  For instance: revision1 contains a rule that permits local 
> access when revision2 removes that access, or when revision1 contains 
> access to a domain that revision2 has removed.  When might this happen? 
> A good example might be when a device is no longer supported by the 
> manufacturer for Internet connectivity, but itself can continue to 
> function independently.
> 
> I think there is a simple approach to dealing with this risk: do not 
> permit rollbacks for a given device.  This text could be placed in the 
> security considerations section.

How do you know that a specific URL is a rollback? It looks easy when 
the example say "revision1" and "revision2", but I am sure there are 
cases where you cannot tell by just looking at the URL. You may be able 
to download the "old" and "new" URL, and check the date of the 
signature. But then, please describe the process so implementers are not 
confused.
> 
> [Nit- there is one instance of mud controller that should be mud manager.]
> 
> Regarding your grammar check, I agree that there is a parser problem, 
> and we should simply change that as follows:
> 
> OLD:
> 
>> The test is simplified to: remove everything to the right of
>>     the last (rightmost) "/" in the URL of "root" MUD file URL, and the
>>     proposed new URL.  The resulting two strings MUST be identical
> 
> NEW:
> 
> The test is simplified as to: remove the last segment of the URL and all 
> text to its right.

Something like that, but please add a pointer to the syntax description, 
to introduce the terms "segment", etc.

> 
>   ABNF does not support removal, so this will have to be narrative.  You 
> may characterize this as a “shotgun parser”, but bullet proofing it 
> starting from a valid URL means about 16 lines of C, 3 lines of python 
> with URLLIB, or probably one long line of SNOBOL.  We could put these in 
> an appendix if you like.

It is not a shotgun parser if you base it on the ABNF of the URL syntax. 
But "look for the rightmost slash" is...
> 
> Regarding the following text:
> 
>> Regarding the security consideration section, I notice that there is a 
>> mild DOS
>> attack possible against MUD Managers and MUD servers. The new MUD URL are
>> advertised using insecure processes, DHCP or LLDP. Attackers with 
>> access to the
>> local network can spoof that. The MUD manager will have to retrieve 
>> and try to
>> validate the new MUD file, which requires a combination of network 
>> access and
>> cryptographic validation, and probably triggers some intrusion 
>> detection system.
> This is really no different than a rogue device generating a random MUD 
> URL.  Similarly, I would prefer not to restate the security 
> considerations of RFC 8520, but simply reference them.

Yes. As I said, it is a mild attack, and yes it is one of many. I don't 
remember seeing it in the security section of 8520, but it would belong 
there. Maybe something to note for a revision.

-- Christian Huitema