Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: 
 <178587221734.584.16465348933486025478@dt-datatracker-54dc84885d-8d5gh>
Date: Wed, 5 Aug 2026 14:16:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <289C0F58-BB3C-498C-AA1D-5BA49BEE9F29@gmail.com>
References: 
 <178587221734.584.16465348933486025478@dt-datatracker-54dc84885d-8d5gh>
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Message-ID-Hash: JIXPUPTKESNN5I5GSXPURCCMWICUDTFV
CC: secdir@ietf.org, draft-ietf-pim-gaap.all@ietf.org, last-call@ietf.org,
 pim@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bsecdir=5D_Re=3A_draft-ietf-pim-gaap-18_ietf_last_call_Secdir_re?=
	=?utf-8?q?view?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/secdir/0qmZHxDO3sl8TAORWHLKKpSN3rA>

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 =E2=80=94
> 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)
> =E2=80=94 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.
>=20
> 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 =E2=86=92 bad-actor list" mitigation can't fire =
=E2=80=94 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 =E2=80=94
> 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.
>=20
> 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.
>=20
> 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
>=20
> The fallback candidates are built by string concatenation (H("foo+1") =
etc.), so
> a legitimate primary name "foo+1" aliases foo's second candidate =E2=80=94=
 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".=20

> Nits
>=20
> Section 6 title: "Detail Protocol Operation" =E2=86=92 "Detailed".
> Section 5.1 code: mismatched parens in format(...) and a missing colon =
on the
> callback def.

We will fix.

Thanks a lot,
Dino