RFC005: Nodes should use a DID to establish their identity

[reinkrul]

Transactions must have a publisher's signature, which must be relatable to a physical, legal entity (hospital, SaaS vendor, etc) e..g. via TLS server certificate.

Update: I think we were missing the "why" in this issue:

• We need a security measures against malicious parties that spam the DAG
• ↳ A solution would be to block parties that spam
• ↳ To block a party, it needs an authenticated identity that can be blocked
• ↳ A party identity could be bound to a X.509 certificate (e.g. PKIo TLS cert which is already required) and/or a DID document specifically for the node.
• ↳ Registration of the node DID document could require a PoW (Proof of Work) so parties can't spam it.

TODO:

• [ ] Introduce a Publisher's DID.
• [ ] Simple proof of work for registration/alteration of publisher's DID (to avoid attackers generating lots of DIDs for spamming/ddos-ing)

Previous TODO/issue from RFC005;

• Peer ID spoofing: peer ID can be spoofed by copying a peer's ID and providing it when connecting to other nodes. Depending on the other peers' implementation, spoofing could be used to impersonate other nodes, which may cause interruptions the other nodes' operation,
  • Possible solution: peer ID MUST be created by generating a P-256 elliptic curve key pair, taking the public key and signing it with the private key.
  • Option 1: signing challenge (downside: requires a handshake, which is complicated).
  • Option 2: signing a nonce (downside: peer needs to track the nonce to make sure it's not used more than once).

[woutslakhorst]

notes from Slack:

This proposal describes three types of nodes: anonymous nodes, public nodes and trusted nodes. For the proposal to work, transactions should be able to support multiple signatures.

Anonymous nodes Nodes may remain anonymous transaction publishers. Their client certificate is not anonymous, but when the network is no longer a full mesh, it's unknown who created a transaction. Anonymous nodes are subject to rate limiting by using PoW.

Public nodes Public nodes are like anonymous nodes but their node endpoint is published in a DID Document. It's not required that there's a correlation between the DID used for signing and the endpoint (although this would be easier to administrate).

Trusted nodes Trusted nodes are like anonymous or public nodes, but they have added a stake to their DID. This is done by publishing a VC with a pkio certificate as payload. This stake will ease the rate limiting for that specific DID. Multiple DIDs may acquire the same stake (same certificate). When irregularities are detected in the published transactions, a choice can be made to ban the pkio certificate. The certificate can then no longer be used to make connections or to ease the rate limiting. The DID can still be used to publish transactions when a new certificate is acquired. There's a certain flexibility in which DID to use for publishing, it may be a DID per node or it may be the SaaS DID. This flexibility can be helpful in different deployment scenarios.

[woutslakhorst]

there's one annoying attack that remains possible:

Eve creates a DID Document with a key that will be used for signing transactions. Eve publishes the transaction to the entire network. Eve creates 2 transactions, 1 where the DID Document is deactivated and 1 with a normal DID Document update (an added service for example). Eve sends tx-1 to Alice and tx-2 to Bob. Both Bob and Alice will accept the new transactions. Next Bob and Alice will send their heads to each other. tx-1 will be accepted by Bob, but Alice can't accept tx-2 since the DID was deactivated already.

It could be solvable, but that would require historic information from the application layer to be available to the network layer. This can become very complicated, very fast.

An alternative approach:

Connect a publishing DID to the Certificate always and check the DID on connect. The attack from above will playout as:

Eve creates a DID Document based on a certificate that will be used for signing transactions and connecting. Eve publishes the transaction to the entire network. Eve creates 2 transactions, 1 where the DID Document is deactivated and 1 with a normal DID Document update (an added service for example). Eve sends tx-1 to Alice and tx-2 to Bob. Both Bob and Alice will accept the new transactions. Alice will put the certificate on a denylist and block Eve. Next Bob and Alice will send their heads to each other. tx-1 will be accepted by Bob, Bob will also disconnect from Eve. Alice will accept tx-2 but will not process the contents. Both Alice and Bob will flag the certificate and notify their node operator.

This would require node DIDs to be handled differently. Their public key remains valid for accepting transactions, but the certificate will no longer be accepted. This would help the network to remain consistent. The complexity is problematic though.

[woutslakhorst]

enter Steve, Eve's cousin. Steve behaves but allows connections from Eve, Steve will continue to broadcast transactions from Eve. Even if Eve is disconnected and under investigation or even in court, it can continue with harassing the network.

[woutslakhorst]

1 part of the puzzle (possibly) solved: expired keys (removed) are still valid but must produce a warning to node operators:

Eve creates a DID Document with a key that will be used for signing transactions. Eve publishes the transaction to the entire network. Eve creates 2 transactions, 1 where the DID Document is deactivated and 1 with a normal DID Document update (an added service for example). Eve sends tx-1 to Alice and tx-2 to Bob. Both Bob and Alice will accept the new transactions. Next Bob and Alice will send their heads to each other. tx-1 will be accepted by Bob Alice will also accept the new tx but since the key was revoked, it'll issue a warning to the node operator.

Then the option of trusted/public/anonymous nodes becomes valid again.