P0. Design rationales
Informative design background for EnkryptedChat-Profile-v0. Normative behavior is in P1–P8.
P0.1 Purpose
This chapter explains why the protocol is shaped as it is. It does not replace normative rules in P1–P8.
P0.2 JSON application PDUs on WebRTC data channels
Choice: UTF-8 JSON objects with a string type discriminator on SCTP data channels.
Rationale:
- Browser-first stack:
JSON.stringify/parseintegrate cleanly with React state and debugging tools. - Inspectability during development: handshake and cascade envelopes can be logged (with secrets redacted) without a custom binary decoder.
- Single implementation: no interoperability requirement for a compact binary codec.
Trade-off: Larger on-wire size than a typed binary protocol (e.g. WireGuard packets). Mitigated by chunking and fast-file paths for bulk data.
Future: An informative EnkryptedChat-Profile-v2-binary MAY be defined later; v0/v1 documentation remains JSON-normative.
P0.3 Cascade order MLS → Signal → ML-KEM → AES
Choice: Four application layers applied in registration order inside CascadingCipherManager.
Rationale:
- MLS (RFC 9420): Group epoch semantics and future multi-device alignment; outermost for group-aware deployments.
- Signal: Battle-tested 1:1 forward secrecy and break-in recovery via Double Ratchet (Appendix B).
- ML-KEM-768: Post-quantum confidentiality layer on message content (not full-PQ transport).
- AES-GCM-256: Fast symmetric envelope keyed from peer-derived material; supports rotation suffix.
Trade-off: Defense-in-depth adds latency and complexity. Cascade is not a substitute for auditing Signal, MLS, or the browser delivery chain.
P0.4 No third-party client interoperability
Choice: One product (Enkrypted Chat) and one codebase family; no version negotiation with external clients.
Rationale: Rapid iteration, module federation, and tight coupling between p2p and glitr-chat. A public interop surface would require frozen schemas and conformance certification before it adds value.
P0.5 Broker-first signaling (PeerJS / WSS)
Choice: Default path uses an online PeerJS-compatible broker for SDP/ICE exchange.
Rationale:
- NAT traversal for browser peers without manual copy-paste in the common case.
- Clear trust boundary: broker is semi-trusted for connection setup, not for message plaintext (P2).
Trade-off: Broker compromise enables signaling MITM until channel binding exists. QR/manual SDP remains a product option (ch. 3) but is out of scope for the v0 protocol profile.
P0.6 Cleartext handshake material (known limitation)
Handshake PDUs (P3) carry key packages and Signal exchange payloads inside JSON on the data channel before encryptionReady. Confidentiality during this phase is partial (P1.4). Encrypting the handshake wrapper is future work.
P0.7 TOFU and optional verification
Peers are addressed by Peer ID on the broker. Cryptographic binding comes from in-band Signal/MLS handshakes, not a global PKI. High-risk deployments SHOULD use safety-number or QR verification (product UX) in addition to TOFU.
P0.8 Related documents
| Topic | Document |
|---|---|
| Normative profile | P1 |
| Signal deltas | Appendix B |
| Supply chain | ch. 8 |
| Change history | CHANGELOG-SPEC |