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

[Dino Farinacci <[e-mail]>]

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