keel link prerequisite: the remote-exposure security pass — bind opt-in, tunnel Host validation, token issuance off loopback

[eaitbrahim]

Prerequisite for every Phase B item (keel link, mobile PWA, ceremony card, push — docs/evolution-plan.md §5 Phase B). Nothing remote ships before this pass.

Where the architecture stands

keel serve binds loopback by design, with a deliberate DNS-rebinding defence (the bind/Host checks in keel/web/server.py — the design comments name the attack and the checklist). 127.0.0.1 is a secure context by specification, which is what the service worker and manifest currently rely on. That posture is correct for today and wrong to weaken: exposing the same server through a WireGuard mesh (Tailscale/Headscale) or a Cloudflare Tunnel changes the threat model, and the current defences will — correctly — reject a tunnel's traffic until they are taught to expect it.

What must be designed, explicitly

• Bind-address configuration — loopback remains the default; an explicit, documented opt-in to bind a mesh interface (Tailscale) that does not weaken the loopback checks
• Host validation for tunnels — Cloudflare Tunnel presents the app's public domain in the Host header; the DNS-rebinding check will rightly refuse it. Add an expected external host allowlist in config; everything not on it is still refused
• One-time session tokens over a remote origin — what each transport actually guarantees, stated honestly (WireGuard mesh is end-to-end between the operator's devices; Cloudflare terminates TLS at its edge — the operator trusts Cloudflare in that mode, and the docs must say so). Token entropy, issuance rate-limiting, expiry, and brute-force posture on a non-loopback origin
• Secure-context re-verification — the PWA/service-worker/manifest behaviors re-verified on the external origin over HTTPS, not assumed from the loopback behavior
• A threat-model note in the docs — what the tunnel protects, what it does not, and what the operator is trusting in each mode

Rules

• The DNS-rebinding defence is never deleted to make a tunnel work; it is extended with explicit expectation. A PR that removes the bind check to make something connect fails review on principle.
• This issue is engine-side only; the tunnel/mesh tooling itself is the keel link issue that follows it.