[secdir] Re: draft-ietf-pim-gaap-18 ietf last call Secdir review

[Mike McBride <[e-mail]>]

Hi Tim,

Thank you for the review. I *think* I captured all of your concerns and
suggestions in the just submitted -20. I utilized Dino's suggestions. I'm
attaching the diff here. Please give it another review and see if I missed
anything.

thanks,
mike



On Thu, Aug 6, 2026 at 9:37 AM Tim Hollebeek <[e-mail]>
wrote:

> Yes, and I think that is the shape of most of the comments. If you're on a
> "safe" network, which can be accomplished in a number of ways, including
> virtually by using pre-shared keys, encryption and authentication, this can
> be made to work. But the security properties are fragile, especially with
> respect to active attacks. The Security Considerations just need to capture
> those details accurately so that readers can make informed decisions about
> how to deploy it safely.
>
> -Tim
> ------------------------------
> *From:* Dino Farinacci <[e-mail]>
> *Sent:* Wednesday, August 5, 2026 5:16 PM
> *To:* Tim Hollebeek <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>
> *Subject:* Re: draft-ietf-pim-gaap-18 ietf last call Secdir review
>
> Thanks for the impressive comments Tim. See inline my responses. I have
> not discussed this with my co-authors.
>
> > Persistent denial of allocation. The four candidate addresses for a name
> are
> > deterministic and computable by anyone who knows the name. Nothing
> requires a
> > receiver to verify that a Claim's name field hashes to the address it
> claims —
> > Section 8's guidance to ignore such Claims is a non-normative lowercase
> > "should." An on-network attacker can therefore contest all four
> candidates with
> > spoofed Claims bearing fabricated early timestamps; the victim yields
> each time
> > and gaap.allocate() returns None with no retry. Even against an
> implementation
> > that does enforce the Section 8 check, the cost rises only to a targeted
> > preimage over the masked bits (~2^22 for the IPv4 /10, ~2^32 for the
> IPv6 /32)
> > — not a barrier. Security Considerations should state that the base mode
> offers
> > no protection against an on-network attacker and is suitable only within
> a
> > trusted domain.
> >
> > Timestamp arbitration is exploitable in the past direction. "Earliest
> wins,"
> > but only far-future timestamps are sanity-checked. An attacker
> fabricates an
> > old timestamp and always wins, indistinguishably from a genuine old
> claim (so
> > the "invalid timestamp → bad-actor list" mitigation can't fire — it only
> > triggers when an even-earlier claim exists, i.e. when the attacker
> loses).
> > Separately, the draft notes an unset post-boot clock reads far in the
> past —
> > such a node legitimately wins every collision, a robustness bug with no
> > attacker present. A far-past plausibility rule symmetric with the
> far-future
> > one seems warranted.
> >
> > Encryption gaps. ChaCha20 alone is malleable (the Marker is a redundancy
> check,
> > not integrity); consider AEAD as MUST-when-encrypting rather than
> SHOULD. Nonce
> > management is unspecified, which is dangerous with one shared key across
> many
> > senders. The cleartext header isn't bound as AEAD associated data.
> Sections 4
> > and 8 contradict each other on whether the Marker stays cleartext
> (Section 4)
> > or is non-0xAAAAAAAA on the wire and only appears after decryption
> (Section 8).
> > And nothing requires a keyed receiver to reject plaintext Claims,
> permitting
> > trivial downgrade.
> >
> > The bad-actor list can be turned into the attack. Since sources are
> spoofable,
> > an attacker can spoof misbehaving Claims from a victim's address to get
> the
> > victim blacklisted, and can inflate the list itself (state exhaustion on
> a
> > stateless protocol). Entries should be bounded and advisory.
>
> Do you believe (with the exception of your encrytion gap comment), if an
> out-of-band shared-key was used and encryption was reliable, problems 1, 2,
> and 4 would go away?
>
> So only authorized users would operate the protocol (and app), even though
> an authorized user could go rogue.
>
> Could we state out-of-band key exchange and satisify your comments?
>
> > Minor
> >
> > The fallback candidates are built by string concatenation (H("foo+1")
> etc.), so
> > a legitimate primary name "foo+1" aliases foo's second candidate —
> reachable by
> > ordinary API allocation, and also by accident. Hash-level domain
> separation of
> > the attempt number would remove this; it does not, however, mitigate
> item 1.
>
> Well the group members joined to "foo" would Claim a collision for "foo+1"
> and the "foo+1" members would move to group "foo+1+1".
>
> > Nits
> >
> > Section 6 title: "Detail Protocol Operation" → "Detailed".
> > Section 5.1 code: mismatched parens in format(...) and a missing colon
> on the
> > callback def.
>
> We will fix.
>
> Thanks a lot,
> Dino
>
>
>
>