A gateway cannot verify that the orchestrator answering a serviceURI holds the registered key

Splitting this out of #437, which was closed as stale. Four of the five parts of that issue describe an architecture that no longer exists. This part does not depend on any of it.

The gap

An orchestrator registers a serviceURI on chain, so a gateway knows which address claims which endpoint. Nothing in the session establishment proves the endpoint holds that address.

Two pieces:

server/segment_rpc.go

var tlsConfig = &tls.Config{InsecureSkipVerify: true}

That is the config used to dial orchestrators, so the certificate is not checked against anything.

net/lp_rpc.proto, OrchestratorInfo carries transcoder, ticket_params, price_info, address, capabilities, auth_token, hardware and pricing. None of it is signed. address is an assertion by the responder, and AuthToken is issued by the responder, so neither demonstrates key possession.

The gateway does sign its own side; the orchestrator recovers the gateway's address from the GetOrchestrator signature. The verification is one-directional.

What that allows

Anyone positioned to answer for a registered serviceURI, by DNS, BGP, a compromised host or a stale record pointing at a reclaimed address, can present themselves as that orchestrator. They choose the ticket parameters and the price, and the gateway has no way to distinguish them from the registered operator.

Why it is worth fixing now rather than in 2018

LIP-118 moves the stake-holding key off the node. That is the right direction, and it makes the node's identity a separate question from its stake: the box answering the serviceURI increasingly does not hold the orchestrator key at all. Whatever proves identity has to work for a node that only holds a delegated or session key.

Possible shape

The eth key cannot be the TLS key, since TLS 1.3 restricts ECDSA to secp256r1, secp384r1 and secp521r1 and Ethereum uses secp256k1. That rules out the 2018 approach but not binding: the orchestrator's eth key signs the certificate public key, the signature travels in a certificate extension or in a signed field on OrchestratorInfo, and the handshake negotiates TLS 1.3 normally with a P-256 key. The gateway checks the binding against the address registered for that serviceURI.

I have a standalone probe of the binding approach and am happy to turn it into a PR if the direction is right. Worth agreeing the shape before I write it.

Start with server/segment_rpc.go and net/lp_rpc.proto, focusing on the insecure TLS configuration and the unsigned OrchestratorInfo fields. Review the proposed certificate-key binding and the standalone probe mentioned in the issue, then define and validate an agreed design in which the gateway can verify the responder against the address registered for the serviceURI.