Skip to content

docs: application membership guide and threat model (R9, R15, R17, R22, R33) - #695

Closed
bahdotsh wants to merge 2 commits into
feat/app-discovery-membershipfrom
docs/app-membership
Closed

bahdotsh wants to merge 2 commits into
feat/app-discovery-membershipfrom
docs/app-membership

Conversation

@bahdotsh

@bahdotsh bahdotsh commented Nov 4, 2026

Copy link
Copy Markdown
Member

Step 12 of the shared-network plan (ADR 0037). This sits at the top of the stack, on #694. Docs only.

Integrator guide: docs/app-membership.md (new, indexed in docs/README.md)

  • What a configured application sees:
    • neighbour events and RSSI for admitted peers only;
    • inbound frames dropped from senders it has not admitted;
    • relaying for everyone, unchanged;
    • offline on the wire, with the real id sealed;
    • air identifiers derived from the key, and sealed discovery.
  • What "admitted" means.
  • Setup:
    • Generating the Ed25519 key pair with openssl, including extracting the raw 32-byte public key and seed.
    • Shipping the public key in app_publisher_key.
    • Backend signing, with a Python example that uses sign_app_membership.
    • set_app_membership on every launch, and app_membership_status.
  • Why the backend's enrolment policy, not proof of address ownership, is the boundary.
  • Embedded signing, and in plain words what it gives away: anyone holding the binary can mint members.
  • Leaf devices: name the leaf through establish_secure_session at the anchor step, then provision_leaf_membership.
  • Rotating the key pair, and losing the key: an outage, not a breach.
  • What membership does not hide: addresses, traffic shape, and recognition by whoever holds the binary.

Threat model

  • R9: sealed, proven discovery for a configured node, and what a hop still sees.
  • R15: the keyed App tag. It is per instance and names nothing, the spoofing analysis is unchanged, and the tag is still linkable.
  • R17: the "what would close it" section becomes "what closes it, for a configured application", with three remaining gaps: unsealed frames, peers without rich payload support, and unconfigured origins.
  • R22: the Wi-Fi Direct values are derived from K_app, so knowing the id no longer admits a device. The values are still one per application, so devices sharing one are linkable.
  • R33 (new): whoever holds an application's binary can recognise its users.
    • A party table covering parties 1 to 3.
    • Recognition happens per connection.
    • In backend mode the enrolment policy is the boundary; in embedded mode the binary holder can forge members.
    • What party 2 still learns.
    • The observable of the gate.

Titles are unchanged, so existing anchors still resolve.

Also

privacy.md is unchanged: it covers only the telemetry disclosures, and this feature collects nothing.

…33 party 3

The integrator guide (key generation, backend and embedded signing,
rotation), the R17 rewrite now that a configured node names no application
on the wire, a new R33 for what whoever holds an application's binary can
still do, and the changelog entry.
…ery in the guide

R9 states sealed, proven discovery for a configured node, R15 the keyed
App tag, R22 the Wi-Fi Direct values from K_app. The guide covers the air
identifiers, sealed discovery and provisioning a leaf, and the ADR's App
tag line names the label and the Device id input that shipped.
@bahdotsh bahdotsh closed this Nov 4, 2026
@github-actions github-actions Bot locked and limited conversation to collaborators Nov 4, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant