Re-evaluate the use of KV-driven incrementing IDs for users, members, nodes and proposals

[eddyashton]

Our incrementing IDs expose CCF users to dangerous mistakes in the presence of rollbacks.

We could remove these IDs entirely. In most places we can instead use the digest of the caller's cert, and the only case this doesn't work is Proposals for which we should be able to generate a UID (on the node, while processing /gov/propose).

[eddyashton]

There is a major caveat to replacing the incrementing IDs, which is that they make it harder to detect and blame replay attacks. We should look at these closely, and work out which are safe or can be made safe (the IDs are only accepted/used once they're globally committed), and which should be replaced by View.IncrementingIndex or by generated UIDs.

[achamayou]

@eddyashton that's only true for UUIDs (ie. proposals), where we can use identity digests there is no problem and it's a clear improvement in rollback situations.

[achamayou]

To clarify, there are a few different items here:

1. Proposals
2. Nodes
3. Users and Members

In the case of proposals, the main risk is confusion. If proposal X comes up, but gets rolled back, it's possible to lodge a vote for/against X that really applies to what's now a different proposal, if another one gets submitted in the interval. In theory, the vote script ought to be precise enough for that not to matter, but it's good defense in depth to make this difficult.

To make this difficult, it's ideal for proposal ids never to be re-used in time (even if they aren't in the committed order of course), and probably good for them not to be too predictable either.

The same applies to node ids, for less important reasons: to avoid operator confusion (not a security problem, but one that affects availability nonetheless), and to make the reconfiguration code more obviously correct. The reconfiguration code involves non-trivial interactions between KV and consensus (see #1368), making it deal with unique ids (again, in time, not in committed order) is a clear simplicity win.

Users are also at risk of confusion to some extent in case of rollback, assuming they are removed by id, for the same reasons as proposals. There is no member removal mechanism at the moment (they are simply flagged), but the same reason would apply if/once there is.

Two more factors to consider are:

1. The benefit of having a consistent id mechanism across identities, be they members, nodes etc.
2. The information leaked in non-random ids, which allows guessing the rate at which identities are added, and potentially the total amount.

[letmaik]

Proposal IDs are digests as of #2104.

For nodes, users, and members, using digests of certs/public keys makes sense.

For nodes, it should be the digest of the public key (instead of cert) as the initial node cert is only temporary and will change when the node joins the network (at which point the public key is endorsed by the network key, creating a new cert with the same public key). For operators it would be cumbersome to have to wait for the new cert to come into existence, download the final node cert etc. rather then just using the stable (digest of the) public key as node identifier.

For users and members, it makes sense to use the cert digest since that will not change. Treating a user with a new cert on the same public key as new user seems fine, for provenance purposes. The only thing to consider before going down that route is to check is whether there is ever a case where a cert can be re-encoded in different formats (PEM/DER -> PKCS #12) such that the cert bytes change as sent as part of the TLS connection. The current assumption is that this is not possible.

[letmaik]

The only thing to consider before going down that route is to check is whether there is ever a case where a cert can be re-encoded in different formats (PEM/DER -> PKCS #12) such that the cert bytes change as sent as part of the TLS connection. The current assumption is that this is not possible.

I had a look at the standards and it's pretty clear that this is safe.

Both X.509 certs and public keys alone are defined in terms of ASN.1. Multiple encoding formats have been defined for ASN.1 over time (one of them DER), and specifically for computing the signature in X.509 certs the DER encoding of the rest of the cert is used as it's an unambiguous and deterministic encoding format of ASN.1 (compared to it's predecessor BER, or PEM, for example). So if we want to use certs as keys, then it is sufficient to use DER encoding as key.

[achamayou]

Thank you for looking into this @letmaik, can I suggest we split this into the following two items:

1. Make node ids a digest of their public key (ie. stable across re-endorsements)
2. Make user and member ids a digest of their cert (ie. entirely specific, re-endorsement is a new identity)