<div dir="ltr"><div class="gmail_default" style="font-size:small">Alice, Bob and Carol want to hold a group chat, Doug through Zeake might join in at some point. How do we establish and manage keys for the channel?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The reason for bringing this up is that I am trying to work out if the ratcheting tree proposed in MLS actually delivers any value.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://tools.ietf.org/html/draft-ietf-mls-protocol-11">https://tools.ietf.org/html/draft-ietf-mls-protocol-11</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The two types of security we are concerned about are:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Forward Secrecy, The conversation remains confidential even if the keys of Alice, Bob Carol etc. are all compromised after the channel is established.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) Post Compromise Security. Alice should be able to have a secure conversation with Bob even if Bob's key is known to Mallet.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The security issue we are not at all concerned about is what happens if Mallet is allowed to join the channel. Clearly the channel is compromised if Mallet learns the channel secret.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">MLS describes a complex protocol in which a tree is constructed and the participants engage in a series of pairwise key exchanges that ultimately result in a consensus key agreement being reached. This tree interested me greatly because I could map it onto threshold techniques. But the more I looked, the more it seems that a much simpler protocol is actually better.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And my experience of using some of the products based on the technique is that they simply aren't reliable. Whether that is because the peer to peer crypto isn't really working or the peer to peer comms...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The first issue is that confidentiality is break once run everywhere. A guarantee that everyone has participated in the generation of a shared secret is irrelevant when every person who participated can disclose the secret itself.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This becomes even clearer if we decide that our channel is going to be encrypted under a randomly chosen session key which is disclosed to the participants by means of a keywrap function.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So in my simplified protocol, we nominate a subset of the group members to act as administrators. In the simplest case we have just one admin, Alice.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To join the group, Bob sends his public key plus a newly created ephemeral to Alice. Alice performs a key exchange on her private key and sends her public key plus an ephemeral of her own back to Bob.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Alice/Bob key exchange is KDF ( a.EB || ea.B ) for Alice, 

KDF ( eb.A || b.EA ) for Bob. Alice uses the result of the KDF to wrap the channel secret and pass it to Bob.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This key exchange achieves forward secrecy with respect to Alice's private key and to Bob's private key. Further it has post compromise security against a passive attack if Alice's private key is compromised OR is Bob's private key is compromised. It will be breached if both are 

compromised

.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Carol joins the group in the exact same way, by performing a key exchange against Alice.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Seems to me that the security guarantee here is only slightly less than that provided in MLS. But why would we expect a communication between Alice and Bob and Carol to be more secure than just Alice and Bob?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Am I missing something here?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Of course, having established the initial keys, we can rotate the channel secret at regular intervals so as to support an OTR like limit on the decryption. And instead of simply rekeying from scratch we will ratchet. But that is a detail.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I see no reason why Alice can't support a channel of up to a hundred users by simply staggering the key update process so it is not overly burdensome. She can also deputize the key agreement to other admins.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In practice, there are no peer to peer communications of more than a few dozen people simply because you can't have a hundred people yacking at once. The social constraints on communication scale far less than the ability to support the necessary crypto. </div></div>