Re: [OPSAWG] [Last-Call] Secdir last call review of draft-ietf-opsawg-mud-acceptable-urls-10

Michael Richardson <> Fri, 23 February 2024 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25D35C14E513; Fri, 23 Feb 2024 09:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oqrVpkn9TPUk; Fri, 23 Feb 2024 09:25:15 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 2073CC14F5F8; Fri, 23 Feb 2024 09:25:14 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6BF43898B; Fri, 23 Feb 2024 12:25:13 -0500 (EST)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id IYvGgf4goT-b; Fri, 23 Feb 2024 12:25:11 -0500 (EST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 8FE4938988; Fri, 23 Feb 2024 12:25:11 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1708709111; bh=KctkQMkai6QfvSqawjNec5wp92OI/FOHgxNSTNi037Q=; h=From:To:Subject:In-Reply-To:References:Date:From; b=VEm+moffzkLAdR6kAKqssrwHYAKLapucVGanH9EfWQx92I6bdK8LbAcHj8hFEuAQY Tk11xz0V1UL8mCZ2s42qg29O4WGQxMGxSw3P9C+qXYWkGEvG9ExXTMw0tgBU/MRlVU tFEsGtk7QDOqY1WgNUm6kei7k2yttSoah007C6pLD8LOQ+4eZDlgb073DuBKq3pPHH KKzp5O7pT2esX79KNAQJ/NrZY+pEbZGQVzr308pjdrdiUy7esMfTIN6cITWLwTegAl uG2svOV1W3tH39qDGPR0raCQcEiMn+3cAAj/I131dumHukAedMRSNva/cQfLGJdfye 39kabmyuEU3ww==
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 8586F1A5; Fri, 23 Feb 2024 12:25:11 -0500 (EST)
From: Michael Richardson <>
To: Christian Huitema <>,,,,
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 23 Feb 2024 12:25:11 -0500
Message-ID: <>
Archived-At: <>
Subject: Re: [OPSAWG] [Last-Call] Secdir last call review of draft-ietf-opsawg-mud-acceptable-urls-10
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Feb 2024 17:25:20 -0000

Thank you for the review, and the summary text.

Christian Huitema via Datatracker <> 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 "", and
    > then upgraded it to a stricter rule in
    > "". 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: 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 <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide