Rethink server ID

[zanebeckwith]

We've talked about this a lot for a while, but I think this should be discussed in earnest here.

The intention of the server ID was to ensure that the specific server machine a client connects to is the one it intended to connect to. It was inspired by TLS libraries that take pains to make sure the responder is the intended URL, and not simply a different machine whose credentials can be validated using a trusted root.

However, this now seems antithetical to the usage of XTT: the client connects to a decentralized "server" and any machine that acts on behalf of that "server" must have a valid credential under the root that represents the "server". The client doesn't care which specific machine it connects to, only that it is an authenticate member of the "server" (i.e. its credential is signed by the correct root).

Retaining the server ID:

• Adds size to the message
• Requires extra processing on the client side
• Most importantly, is a burden on the user of the client software, to have to manage a server ID

[zanebeckwith]

@drbild and @kathrynfejer I would be interested in your opinions on this

[drbild]

TLDR: Agreed on the main two points above, the original intention and its antithetical nature now. We should remove the server ID concept.

Here's an avenue of thought that I originally thought might support keeping the server id.

Consider a device that is deployed while connecting to the Xaptum ENF. Some time later, the owner wants to transition to a different backbone network provider.

How can the device authenticate the new provider?

Xaptum can't issue server certificates (without a server id) for the new provider under that root certificate, because then other Xaptum customers might connect to the new network. With a server id, the certs could be issued on a server id specific to the new provider.

However, the device would need to be updated to accept the new server id. And if that update can be made, its easy to just update the root certificate directly.

[drbild]

Another avenue of thought along those lines.

What if the server id concept were replaced with something specific about the client? E.g., the server cert included the group id, for example. The groups could be transferred to different owners, with Xaptum as the root CA, no changes on the client required.

However, there'd need to be a way to expire certificates. We can't rely on short-lived certs, since we don't want to require a synced clock.

All in all, this doesn't seem to go anywhere useful.

[zanebeckwith]

My sense is that solutions like this keep coming back to "if that update can be made, its easy to just update the root certificate directly." Ha.

As it stands now, the client offers no indication of to whom it wants to connect in its ClientHello message, so the server would never know how to offer a more-specific server certificate.

I think there should be a discussion on whether to have the client indicate, in the ClientHello, which root it will accept. This would allow transfer of ownership, via transfer of root CA (albeit, still requiring a change to be made to the client), and it would also allow a single backbone provider to support multiple root CAs (e.g. if a specific customer wants to operate their own CA, but still let Xaptum operate the network). The downside (and the reason this wasn't originally included in the design) is that this leaks identifying information from the client before it's authenticated the server (allowing a passive adversary to learn which root the client wants to connect to).

But that's still orthogonal to the decision to keep the server ID. The point remains that the root ID identifies which "network" or generalized "server" the client wants to connect to, and the server ID just doesn't have any meaning.

Supporting zero-touch ownership-transfer would be great, but I agree: I don't see a way that the server ID allows us to do that.

[drbild]

Agreed. Let's remove the server id. We can transfer the ClientHello discussion to a different issue.

[zanebeckwith]

Agreed