Re: [OPSAWG] [Last-Call] Secdir telechat review of draft-ietf-opsawg-mud-acceptable-urls-11

[Christian Huitema <[e-mail]>]

Sorry about that -- I botched the copy of my review into the web form. 
The first paragraph should read:

In my initial security review of this draft 
(https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-acceptable-urls-10-secdir-lc-huitema-2024-02-19/), 
I made a number of recommendations.

On 4/2/2024 11:56 AM, Christian Huitema via Datatracker wrote:
> Reviewer: Christian Huitema
> Review result: Ready
> 
> acceptable-urls-10-secdir-lc-huitema-2024-02-19/), I made a number of
> recommendations.
> 
> One of the first recommendation was to clarify whether the distinction between
> "small changes" and "big changes" was really necessary, and maybe to just keep
> the stricter "big changes" process. The authors did not do that, probably based
> on their assessment of deployment considerations. However, they did address the
> substance of the issue in several ways.
> 
> The draft now explicitly uses the same "small change/big change" terminology
> that I used in my review. That's a good way to clarify the issue. In the "small
> change" section, the draft now uses explicit references to the URL syntax in
> RFC3986, instead of the "righmost '/'" text that was encouraging "shotgun
> parsing". That's good.
> 
> The previous "small change" process was vulnerable to "rollback" attacks, in
> which an attacker would reuse an old, more permissive, version of the MUD URL.
> The new draft version addresses that issue explicitly, asking MUD managers to
> keep track of previous versions so as to detect such rollback attacks. The
> authors assess that keeping such logs is practical, and I am ready to believe
> them.
> 
> The previous security review pointed out that the use of "detached signatures"
> when evaluating "big changes" was somewhat unspecified. The introduction of
> section 4 now includes an explicit reference to Section 13.2 of RFC8520 where
> this problem is defined.
> 
> I added to my previous comment a remark about the possibility to generate
> spurious intrusion alarms by sending spoofed messages through DHCP or LLDP. The
> authors pointed out that this such spoofed messages can only happen if the
> local network has been breached, and thus are valid alarms. There is already a
> related discussion in section 3.2, with references to the "boy cries wolf"
> issues.
> 
> The new draft version feels significantly improved from the version that I
> reviewd, and I believe that my concerns have been addressed.
> 
>