Security Considerations

Security model, spam prevention, and protection mechanisms for federated communication.

Trust Model

DNS-Based Trust

  • Domain ownership proves identity
  • TLS certificates prove server authenticity
  • Action signatures prove content authenticity

Progressive Trust

  • Initial federation is cautious
  • Trust builds through successful interactions
  • Users can block instances/users

Spam Prevention

Relationship-Based Acceptance

After a token’s signature is verified, the receiver decides whether to accept it based on the relationship with the issuer. The gate is type-agnostic:

  • If the issuer’s local profile is Suspended, Blocked, or Banned, the action is rejected outright.
  • Otherwise the action is accepted if the receiver follows the issuer or has a connection with them.
  • A few subject-anchored exceptions admit strangers on public content, e.g. a REACT or REPOST referencing the receiver’s own public action, or a STAT update for content the receiver already holds.
  • A container owner’s vouching APRV is accepted from a stranger when its parent is a container we already hold whose type declares relay_children, and the APRV’s issuer owns that container. This is what lets conversation members accept each other’s messages without a direct relationship — see Trust & Content Distribution. The APRV’s own signature is verified first, so the vouch cannot be forged, and the token it bundles is re-checked against the APRV’s subject.
  • Anything else from an unrelated stranger is rejected.

Proof of Work for Connection Requests

CONN actions arriving at the inbox must include a valid proof-of-work token bound to the sender’s IP. Missing or invalid PoW is rejected with 428 Precondition Required. This raises the cost of bulk, unsolicited connection requests without requiring a prior relationship.

Rate Limiting

Inbound requests pass through a tiered IP rate limiter (per individual address and per network/provider block) shared by the whole HTTP surface, not a separate federation-specific limiter. Token-verification failures also penalize the source IP, so an instance sending many bad signatures is throttled.

Blocking

Blocking is expressed through the issuer’s local profile status. Setting a remote user’s profile to Blocked or Banned causes all of their subsequent actions to be refused during the acceptance check described above. There is no separate instance-wide blocklist; blocking is per-profile.

Signature Verification

Every federated action token must pass signature verification before it is accepted:

  1. Key fetch - the issuer’s public key (selected by the token’s key ID) is retrieved from the issuer’s instance, with caching.
  2. JWT signature - the ES384 signature is checked against that key, proving the token was signed by the claimed issuer.

See Key Verification for the caching strategy and failure handling.

id_tag Validation and SSRF

A peer’s base URL is derived from its id_tag by string prefix — https://cl-o.{id_tag}/api{path} — and that id_tag originates in the iss / aud claims of an action token, which are attacker-controlled. Without a guard, a crafted value could inject a path, query, fragment, userinfo or port into the request target: server-side request forgery, or request smuggling.

Every outbound federation request therefore validates the id_tag before building the URL (host_for in cloudillo-core). The validator forbids /, @, :, whitespace, _ and uppercase, which leaves only a canonical DNS-style name. Stored id_tags are UTS #46 U-labels, so an internationalized identity is punycoded to its A-label on the way out — DNS and TLS only speak ASCII. The resulting host is pure LDH ASCII by construction.

See Also