Problem: MLS member leaving/joining interaction with council nodes not documented #141

tomtau · 2020-05-19T06:54:03Z

From the audit discussion

Who among the validators invites a newcomer when a new validator node joins?
Assuming TDBE is (in normal circumstances) provided with network updates (relevant transactions, events...), it'll go like this:
block N (time N_t), there's a valid NodeJoinTx with a metadata payload, including a ClientInitKey
TDBE corresponding to node with index 0 in the ratchet tree generates "Welcome" and "Send" payloads wrapped in a single MLS-related transaction that's then broadcasted/gossiped by Tendermint (let's call it MlsAddTx)
block M (time M_t), MlsAddTx is proposed to be in a block:
if M_t <= N_t + timeout, it's considered valid and propagated to validator TDBEs
if M_t > N_t + timeout, it's considered invalid and the process restarts with Step 2., but TDBE corresponding to a node with index 1
(and this may continue with indices 2,3,... the consensus assumption is <1/3 of nodes are malicious)
One consequence of this is there may be multiple MLS Welcome/Send payloads for one newcomer -- only one of them is applied.

Who among the validators triggers the group and key update when a validator node leaves?
Same logic as above with joining, but there multiple ways to trigger "validator node leaving" (operator decides to leave and broadcasts relevant transaction, its node was observed to be faulty, ...)

I guess for the nodes that are not in the validator set, but requested to join / have enough stake, their TDBE keypackage will still be a part of the MLS group structure and expected to generate those MlsAddTx transactions/react to the network changes.

For nodes not generating these update Txs in time, they may need to be punished

tomtau · 2020-05-27T02:21:52Z

Also one thing TBD -- how's it done during genesis. I guess options are:

one of the initial validators is expected to generate the MLS payloads prior to genesis.json creation and they'll be dumped into genesis.json and processed by initial validators
they'll be just keypackages, as now, and one of the initial validators will be expected to generate and broadcast a TX with MLS payloads post-network launch within some time limit (following the same/similar logic as with joining/leaving)

yihuang · 2020-05-27T03:29:03Z

Also one thing TBD -- how's it done during genesis. I guess options are:

one of the initial validators is expected to generate the MLS payloads prior to genesis.json creation and they'll be dumped into genesis.json and processed by initial validators

they'll be just keypackages, as now, and one of the initial validators will be expected to generate and broadcast a TX with MLS payloads post-network launch within some time limit (following the same/similar logic as with joining/leaving)

Option 1 looks more stable, need less synchronized actions among different parties.

tomtau · 2020-06-02T09:03:12Z

One more thing TBD from Slack @devashishdxt : how to deal with expired certs -- Update proposal logic https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#update (trigged automatically? if so, how to prevent DOS; or semi-manually / needed to be signed by the operator's staking key? ...)

…t documented (WIP crypto-com#141 fixes crypto-com#142) Solution: sketched out a doc containing more details beyond the original implementation plan (it still lacks some parts, so still WIP) + some parts -- e.g. new transaction types -- can be moved to other modules when it's agreed on and detailed/polished later -- also, as the MLS protocol draft changed since the original implementantion plan, key rotation procedure was simplified to make use of MLS exporter functionality

…t documented (WIP #141 fixes #142) (#152) Solution: sketched out a doc containing more details beyond the original implementation plan (it still lacks some parts, so still WIP) + some parts -- e.g. new transaction types -- can be moved to other modules when it's agreed on and detailed/polished later -- also, as the MLS protocol draft changed since the original implementantion plan, key rotation procedure was simplified to make use of MLS exporter functionality

…t documented (WIP crypto-com#141) Solution: - revised the proposed design, so that joining is immediate (node fetches MLS handshakes directly from remote TDBE instead of waiting for commit message) - sketched out basic types for NACK - sketched out a state diagram and explanation of transitions with regards to different events and MLS handshake messages

…t documented (WIP #141) (#179) Solution: - revised the proposed design, so that joining is immediate (node fetches MLS handshakes directly from remote TDBE instead of waiting for commit message) - sketched out basic types for NACK - sketched out a state diagram and explanation of transitions with regards to different events and MLS handshake messages

…to-com#1967) Solution: updated the data types according to the latest doc https://github.com/crypto-com/chain-docs/pull/179/files - chain-abci part was moved to extras module of mls for validation (when crypto-org-chain/chain-docs#141 is done implementation could go there) - in order not to break tx format, confidential init is still takes as Vec<u8> - as tdbe workflows aren't ready yet, a temporary wrapper was put in the client

1977: Problem: tdbe types are not up to date with latest design (fixes #1967) r=tomtau a=tomtau Solution: updated the data types according to the latest doc https://github.com/crypto-com/chain-docs/pull/179/files - chain-abci part was moved to extras module of mls for validation (when crypto-org-chain/chain-docs#141 is done implementation could go there) - in order not to break tx format, confidential init is still takes as Vec<u8> - as tdbe workflows aren't ready yet, a temporary wrapper was put in the client Co-authored-by: Tomas Tauber <[email protected]>