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

[Eliot Lear <[e-mail]>]

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.

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.

[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.

  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.

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.

Regards,

Eliot