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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
