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

[tomtau]

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]

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

1. 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
2. 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]

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

1. 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
2. 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]

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? ...)