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

[Tim Hollebeek <[e-mail]>]

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