Thank you for the review, and the summary text.
Christian Huitema via Datatracker <noreply@xxxxxxxx> wrote:
> This process generally looks sound, but the "detached signature" part
> is under specified. Is this an implicit reference to PKCS7? How is the
> MUD Manager supposed to retrieve the detached signature?
I think that this is really an RFC8520 issue.
Detached signatures are, yes, assumed, and section 13 of RFC8520 explains them.
> 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";, and
> then upgraded it to a stricter rule in
> "https://example.com/widget-x/revision2.html";. The common prefix rule
> will not prevent the virus from "rolling back" to revision1. A simple
Yes, that's a true observation.
> The "rolling back" problem would of course disappear if the draft
> proposes just one solution for all changes, and followed the "big
> changes" rules regardless of how many characters match between old and
> new URL. I would recommend doing just that.
I'd like to think about this, and I'd like some opinion from others about
this change.
> If the authors really want to keep the "small changes" rule, they need
> to fix its specification. In the current draft, a change is considered
> small if the old and new URL start with the same prefix. To quote:
> "remove everything to the right of the last (rightmost) "/" in the URL
> of "root" MUD file URL, and the proposed new URL." Such description
> makes me cringe, because it amount to describing a "shotgun parser"
> (see: https://langsec.org/papers/langsec-cwes-secdev2016.pdf). Compare
> that to the description of a valid HTTPS URI in RFC 9110:
So I'm not entirely sure I understand your proposed change to mitigate the
problem. I understand that you do not like the description, and this can
perhaps be updated: I didn't find that 9110 had enough specific things to
deal with this situation.
> https-URI = "https" "://" authority path-abempty [ "?" query ]
> And the definitions of path-abempty and query in RFC 3986:
> path-abempty = *( "/" segment ) segment = *pchar query = *( pchar / "/"
> / "?" )
> The shotgun parser will fail if the query string includes a "/", which
> can have consequence such as refusing to accept an otherwise valid
> URL. Please rewrite that description using proper references to RFC
> 3986 and RFC 9110.
okay, I will see if I can make use of the "segment" ABNF.
> 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.
Yes, agreed.
If it would trigger some intrusion detection systems, then likely any
activity by the MUD manager would. If it's the specific URLs that the IDS is
looking at (and the attacker is using), then it seems like the triggers would
be legitimate. There is an attack going on.
> In the security considerations, I would also outline that the
> comparison between "old" and "new" URL assumes that both can be linked
> to the same device identity, presumably based on L2 identity such as
> MAC address. A virus could break that by changing the MAC address of
> the device.
yes, but if the virus/malware changes the mac address, then none of the
existing rules ought apply, and effectively, this is a new, unauthorized
device. It also will break any existing WPA keying, so the device would have
to do some rekeying, perhaps even onboard again.
> There is some discussion of the device identity issue in
> the security considerations of RFC8520. It might be useful to outline
> the identity issue in the security consideration, and point to the
> relevant content in RFC8520.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
