docs(security): RFC — fix the mesh crypto handshake (N3-N5)

[gHashTag]

Proposal for review before implementation. Addresses the 3 crypto defects from the wave audit: unauthenticated handshake (ee+ss only, ss passed as es/se, no transcript hash, AllowList unused, MITM test inverted), constant HELLO MAC key with verify_mac never called, and NodeId-derived static keys. Specifies the fix over the existing X25519+ChaCha20 primitives + a test plan + owner decisions. Crypto stays hand-written Rust (t27 can't express it, #62). See docs/SECURITY_crypto_handshake_RFC.md. phi^2 + phi^-2 = 3

[gHashTag]

Implementation analysis — the two defects address DIFFERENT attacks (sharpens the design)

Started prototyping the handshake fix; found a subtlety that confirms this needs design review before coding, and sharpens the RFC:

es/se and the allow-list defend against different threats — both are required:

• Real es/se + transcript hash gives forward secrecy and binds the statics into the key, defeating a PASSIVE relay that does not hold a valid static key. Implementation note: NoiseXX.ephemeral is an EphemeralSecret (consumed by the first diffie_hellman), so computing ee AND es AND se needs it changed to a reusable StaticSecret; the es/se args are role-swapped (initiator: es=e_i·s_r, se=s_i·e_r; responder mirrors). Verifiable by the existing handshake round-trip tests staying green.
• Allow-list gating is what actually stops the noise_xx_resistant_to_mitm scenario. In that test Alice completes the handshake directly against Mallory's ephemeral+static; with correct es/se she and Mallory STILL derive the same key, because Mallory IS the endpoint she handshook with. The only defense is Alice REJECTING a peer_static that is not Bob's allow-listed key. That requires complete_initiator/responder to take the expected identity and return Result<Session, MeshError::Auth> — an API change touching every caller (daemon, StaticKey::session_with, tests).

Consequence for the plan: the fix is not a one-line es/se swap; it is (a) es/se+transcript for forward secrecy AND (b) a Result-returning allow-list gate for identity. (b) is the load-bearing authentication fix and is the API change that needs owner sign-off (how the daemon threads expected-peer identity into the handshake). So this stays a reviewed change, not a blind overnight edit — the RFC's decision list stands, with "how to thread the AllowList / expected peer id" now the primary decision.

phi^2 + phi^-2 = 3

[gHashTag]

Triage — KEEP

Verdict: KEEP — RFC document, chistyi add (80+ lines, 1 file). Pairs with code PR #65.

Same cascade as other docs PRs: baseline CI red due to committed gen/rust/ from three t27c optimizer scan bugs. Fix chain t27#1461 → t27#1462 → tri-net#80. After #80 lands, this PR goes green without touching a byte here.

No action required. Stays DRAFT.

phi^2 + phi^-2 = 3