The spec makes strong and mostly well-founded security claims, and several of its trade-offs (no content forward secrecy, publishing-key correlation in §15.4.3, no quid-pro-quo in connections in §14.1) are already documented with admirable honesty. A consolidated Security Considerations section — standard in IETF-style specs — would be the right home for the remaining items, which are currently unstated:
1. Metadata visible to the server. "Full end-to-end encryption" holds for content, but the server necessarily learns: who polls a profile (IP, timing → follower set and reading habits); which reader-key ids each client presents (reader is a persistent pseudonym linking every request to a connection identity); the full key-graph shape, group sizes, and rotation events (a round-key rotation is a legible "someone was removed" signal); and per-publishing-key correlation of contributions. Suggest stating this explicitly, recommending the reader parameter move out of the URL query string (query strings persist in access logs and intermediary tooling) into a header or POST body, and noting proxy/Tor polling as the mitigation for follower anonymity.
2. Transport security is optional. §2 says "preferably over TLS" and §1.2 lets clients optionally support http. Reader-key ids, connect/publish tokens, and polling patterns then traverse plaintext. Suggest requiring HTTPS at least for any endpoint handling reader parameters, tokens, or POST bodies.
3. Trust-on-first-use at graph entry. Profile references pin keys (§6) — good — but the first contact with a URI (typed, QR, bridge) is TOFU, and profiles without any key are permitted (§1.1). Suggest documenting the TOFU boundary and recommending clients visibly distinguish keyless (unauthenticated) profiles.
4. Custom canonicalization (§8.1.1). Canonical JSON is defined in three lines; number formatting, unicode edge cases, and duplicate-key handling are unspecified. Canonicalization divergence between implementations is a classic signature-verification failure source. Suggest adopting RFC 8785 (JCS) or, alternatively, fully specifying the edge cases and publishing a signature test-vector suite.
5. Handshake forward secrecy. Connection requests are ECDH-ES against a static X25519 connect key and carry the ephemeral establishment key, which in turn protects the connection packages containing reader keys. A server (or network observer, given point 2) retaining ciphertext can decrypt historic handshakes — transitively down to reader keys — if the static connect key ever leaks. The spec's rejection of forward secrecy for content (Overview) is well-argued, but the handshake is a separate case. Suggest: recommend periodic connect-key rotation, and require (not just enable via PME cleanup) servers to delete relayed connect messages/packages after pickup.
Happy to draft the section if the maintainers agree on scope.
*Disclosure: these findings came out of an AI-assisted review of the spec; I have verified the cited sections against the current master text.*
The spec makes strong and mostly well-founded security claims, and several of its trade-offs (no content forward secrecy, publishing-key correlation in §15.4.3, no quid-pro-quo in connections in §14.1) are already documented with admirable honesty. A consolidated Security Considerations section — standard in IETF-style specs — would be the right home for the remaining items, which are currently unstated:
1. Metadata visible to the server. "Full end-to-end encryption" holds for content, but the server necessarily learns: who polls a profile (IP, timing → follower set and reading habits); which reader-key ids each client presents (
readeris a persistent pseudonym linking every request to a connection identity); the full key-graph shape, group sizes, and rotation events (a round-key rotation is a legible "someone was removed" signal); and per-publishing-key correlation of contributions. Suggest stating this explicitly, recommending thereaderparameter move out of the URL query string (query strings persist in access logs and intermediary tooling) into a header or POST body, and noting proxy/Tor polling as the mitigation for follower anonymity.2. Transport security is optional. §2 says "preferably over TLS" and §1.2 lets clients optionally support
http. Reader-key ids, connect/publish tokens, and polling patterns then traverse plaintext. Suggest requiring HTTPS at least for any endpoint handlingreaderparameters, tokens, or POST bodies.3. Trust-on-first-use at graph entry. Profile references pin keys (§6) — good — but the first contact with a URI (typed, QR, bridge) is TOFU, and profiles without any key are permitted (§1.1). Suggest documenting the TOFU boundary and recommending clients visibly distinguish keyless (unauthenticated) profiles.
4. Custom canonicalization (§8.1.1). Canonical JSON is defined in three lines; number formatting, unicode edge cases, and duplicate-key handling are unspecified. Canonicalization divergence between implementations is a classic signature-verification failure source. Suggest adopting RFC 8785 (JCS) or, alternatively, fully specifying the edge cases and publishing a signature test-vector suite.
5. Handshake forward secrecy. Connection requests are ECDH-ES against a static X25519 connect key and carry the ephemeral establishment key, which in turn protects the connection packages containing reader keys. A server (or network observer, given point 2) retaining ciphertext can decrypt historic handshakes — transitively down to reader keys — if the static connect key ever leaks. The spec's rejection of forward secrecy for content (Overview) is well-argued, but the handshake is a separate case. Suggest: recommend periodic connect-key rotation, and require (not just enable via PME cleanup) servers to delete relayed connect messages/packages after pickup.
Happy to draft the section if the maintainers agree on scope.
*Disclosure: these findings came out of an AI-assisted review of the spec; I have verified the cited sections against the current master text.*