Change:
choose to ignore it (if the value is not known, or if transcript security is not required). <del> 9. Key Secrecy Authentication Re-use of InitKeys </del> 10. <del> 11. The Asynchronous Ratcheting Tree is the building block around which this protocol is built.  It was originally specified by Cohn-Gordon et al with a formal proof of its security properties (https://eprint.iacr.org/2017/666). ART uses a Diffie-Hellman Key Tree to derive a shared secret for a group, allowing it to be efficiently updated (ratcheted) by any group member (leaf node) to provide the properties of Forward Secrecy and Post-Compromise Security.  Alongside ratcheting, receiving messages, and changing the group membership can also be efficiently achieved. 11.1. ART uses a recursive structure, in which every node is a Diffie- Hellman public key or key pair.  The value of a given parent node's private key is computed as follows: (TODO: define our KDF). The ART root secret is the private Diffie-Hellman key of the root of the tree.  This should not be used directly within the protocol, but rather computed into a Stage Key (TODO: below). For this document, we will use the shorthand notation [A,B] to indicate KDF(DH(Alice, Bob)). 11.2. Changing a leaf DH key will inherently update its entire path to and including the root. In the above tree, if C updates to C', the path of all nodes referencing C is updated, resulting in the below tree. C must transmit the public keys of her entire path to the other participants in the tree.  Each participant will update their copath with their respective element from this path, and thus recompute the same updated tree that C has computed. 11.3. 11.4. 12. [[ Session comprised of (1) ART (2) pre-stage key (3) message key chains ]] [[ Each node caches... ]] 13. In MLS, the endpoints involved in a session collaborate to establish and maintain an Asynchronous Ratchet Tree for the session.  There are three major phases in the life-cycle of a group: Initializing the tree Adding a new endpoint Updating a leaf in the tree Leaves are never removed from tree.  One endpoint can remove another endpoint by updating that endpoint's leaf to a key that the endpoint being removed does not possess. At any point, an endpoint can publish a PreKey message, which contains information that another endpoint can use to add that endpoint to a group.  Typically applications provide a PreKey cache to which endpoints periodically push fresh PreKey messages. Suppose an endpoint A wants to initiate a group conversation with otehr endpoints B, C, and D.  A accomplishes this by downloading PreKeys fro B, C, and D, computing a tree over (A, B, C, D), and sending different individual Setup messages to B, C, and D. If A subsequently wants to add another endpoint E to the conversation, then the process is similar.  First A downloads a PreKey for E and uses it to add E to the tree.  From these computations, A generates a Setup message for E and an Add message that can be broadcast to B, C, and D. Upon being added, E should update its leaf key so that its leaf key will not be known to A.  To update a leaf key in the tree, an endpoint simply generates a new key pair, creates an Update message, and broadcasts it to the group. 13.1. Each MLS endpoint caches a view of the overall tree including certain global elements and certain elements specific to the endpoint: For the group: The current epoch The list of identity keys for the group The current frontier The current preStageKey For the endpoint: Index in the tree Leaf key pair Copath MLS messages synchronize this state information across the participants in the group. Note that no state is modified when an endpoint sends a Setup, Add, or Update message.  Because all endpoints need to process updates to the tree in the same order, there is a risk that any given message of these types will be rejected.  To avoid the need to roll back on such rejections, endpoints only apply Setup / Add / Update messages once they are published and accepted by the group.  For more discussion of how modifications to the tree should be sequenced, see #sequencing- of-modifications. 13.2. 13.2.1. 13.2.2. 13.2.3. 13.2.4. 13.3. [[ Endpoints need to make modifications to the tree in the same order.  How does that happen? ]] 14. </del> <ins> 10.1. </ins> <del> [[ What trust is placed in the server? ]] </del> <ins> 10.2. </ins> <del> 15. </del> <ins> 10.3. </ins>

Discussion:
This PR adds a pretty complete description of the protocol. The only major thing that's missing is , which should be straightforward-ish to construct. NAME want to take a stab at that?