Context
transports/nostr.md, lines 117-119:
"Security note: group_event_key is scoped to one MLS group epoch, so nonce uniqueness for a given key rests on the 12-byte random nonce. The bounded number of kind 445 events in one epoch keeps random 96-bit nonces well inside the birthday bound for this outer ChaCha20-Poly1305 layer."
Defect
This is the only place in the spec asserting that kind 445 events per epoch are "bounded." No MUST/SHOULD anywhere in the spec (nostr.md, protocol-core/group-state.md, protocol-core/convergence.md) establishes an actual cap on messages per epoch or a forced re-key threshold. The security claim is presented as settled fact but depends on an unstated protocol invariant. In practice the 96-bit nonce space makes this a non-issue at any realistic message volume, so this is a documentation/completeness gap rather than an exploitable one.
Failure scenario
A future implementation or reviewer reading only this note could assume a per-epoch message cap exists elsewhere and never enforces one, or could mistake this informal rationale for a substantiated normative bound when none exists.
Suggested fix
Either state the actual assumption explicitly (e.g. "assuming fewer than N messages per epoch, which is far below realistic usage"), or rephrase to make clear this is a probabilistic argument based on realistic usage patterns rather than an enforced protocol bound.
Context
transports/nostr.md, lines 117-119:Defect
This is the only place in the spec asserting that kind
445events per epoch are "bounded." No MUST/SHOULD anywhere in the spec (nostr.md,protocol-core/group-state.md,protocol-core/convergence.md) establishes an actual cap on messages per epoch or a forced re-key threshold. The security claim is presented as settled fact but depends on an unstated protocol invariant. In practice the 96-bit nonce space makes this a non-issue at any realistic message volume, so this is a documentation/completeness gap rather than an exploitable one.Failure scenario
A future implementation or reviewer reading only this note could assume a per-epoch message cap exists elsewhere and never enforces one, or could mistake this informal rationale for a substantiated normative bound when none exists.
Suggested fix
Either state the actual assumption explicitly (e.g. "assuming fewer than N messages per epoch, which is far below realistic usage"), or rephrase to make clear this is a probabilistic argument based on realistic usage patterns rather than an enforced protocol bound.