Skip to content

serviceability/sentinel: replace the sentinel exemption from IP ownership proof validation #4215

Description

@elitegreg

Part of RFC-27 (rfcs/rfc27-ip-verification.md); tracker #4194.

Context

#4197 added onchain IpOwnershipProof validation to CreateUser / CreateSubscribeUser, gated on the require-ip-ownership-proof feature flag. With the flag set, a valid proof is required for every user creation — except when the transaction payer is globalstate.sentinel_authority_pk.

The exemption exists because the shred-oracle path has no proof it could obtain. crates/sentinel/src/dz_ledger_writer.rs builds CreateSubscribeUser with owner set to the validator and the sentinel as payer. The proof binds the owner (the account the AccessPass is keyed on and the party that operates client_ip), so it would have to name the validator for an address the verification service never sees a request from. Without the exemption, setting the flag would break every oracle-provisioned multicast publisher with IpOwnershipProofRequired (105).

Why this needs revisiting

The exemption is not reachable by a registrant — it requires a DoubleZero-operated key — so it is not the wildcard-pass hole RFC-27 closes. But it is a privileged path that can bind any client_ip without demonstrating control of it, and the residual risk is that a compromised sentinel key can do so silently. Note also that InitGlobalState seeds sentinel_authority_pk to whoever initialized global state, so in a fresh environment the exemption belongs to the deployer until the key is rotated.

Scope

Decide and implement how the oracle path demonstrates IP control, then narrow or remove the exemption. Options, roughly in increasing cost:

  • Validator-supplied proof, relayed by the oracle. The validator obtains a proof for its own address out of band and the oracle attaches it. The program already validates a proof the sentinel supplies, so this needs no program change — only a way for the validator to hand a proof to the oracle, and a decision about how long it stays valid (the freshness window is one epoch).
  • Narrow the exemption. Restrict it to the multicast-publisher shape the oracle actually creates (owner_override set, UserType::Multicast) rather than any creation the sentinel pays for.
  • Verify at access-pass issuance instead. The oracle already issues the EdgeSeat pass; if IP control were established there, the user creation would not need a proof at all. This is the "verify at issuance" alternative the RFC considers, applied to just this path.

Acceptance

  • The oracle path either carries a real proof or is covered by a deliberately narrowed exemption, documented in the RFC.
  • Test coverage for the chosen path with require-ip-ownership-proof set.
  • If the exemption survives in any form, doublezero permission audit or an equivalent surface reports it, so it is not an invisible privilege.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions