Draft: draft-ietf-mls-protocol

Commentary: Fixes for points 1 , 2 , 4 , 7 in . 
 I think a bunch of these are probably relics of previous versions . For reference , the page numbers listed are from the PDF version of draft 3 of the protocol : [ x ] 1 - p6 : is mentioned , but it is not defined anywhere in the specification . Perhaps is intended.[x ] 2 - p19 : A field is mentioned , but only is present . Also it 's unclear which function is supposed to be used here . It ca n't be ciphersuite - dependent , since it has to be the same for every Participant.[x ] 3 - p22 : is used in a diagram , but never defined . I think this is important , and it 's mentioned elsewhere.[x ] 4 - p24 : is mentioned , but never defined . Is it supposed to say ? [ ] 5 - p25 : The underlying Hash that HMAC uses ca n't be defined by anyone 's ciphersuite . This is group state , and everyone has to agree on this.[x ] 6 - p28 : Mentioned " update secret " again without explanation.[x ] 7 - p29 : " identity tree " is mentioned , but I ca n't tell what that 's referring to . Also " update secret " is here.[x ] 8 - p35 : is mentioned , but never defined . Perhaps is intended . 
 Thanks a lot for the review , this is very useful . I have a pass planned for this week and will fix these issues :) 
 A PR was opened with fixes for points 1 , 2 , 4 , 7 . Point 8 was already solved . An issue has been opened to solve points 3 and 6 related to the update secret definition . I tried to figure out your point 5 but I did n't understand it , can you give details ? 
 Sorry for the delay . I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol . I 'm still not 100 % clear on it , but I think I 'm just missing something simple . Consider it withdrawn . 
 Ok , then these issues are fixed by and . Thanks
Paragraph (version A):
We describe the information stored by each participant as a _state_,
which includes both public and private data.  An initial state,
including an initial set of participants, is set up by a group
creator using the _Init_ algorithm and based on information pre-
published by the initial members.  The creator sends the _GroupInit_
message to the participants, who can then set up their own group
state and derive the same shared secret.  Participants then exchange
messages to produce new shared states which are causally linked to
their predecessors, forming a logical Directed Acyclic Graph (DAG) of
states.  Participants can send _Update_ messages for post-compromise
secrecy and new participants can be added or existing participants
removed from the group.
Paragraph (version B):
We describe the information stored by each participant as a _state_,
which includes both public and private data.  An initial state,
including an initial set of participants, is set up by a group
creator using the _Init_ algorithm and based on information pre-
published by the initial members.  The creator sends the _Init_
message to the participants, who can then set up their own group
state and derive the same shared secret.  Participants then exchange
messages to produce new shared states which are causally linked to
their predecessors, forming a logical Directed Acyclic Graph (DAG) of
states.  Participants can send _Update_ messages for post-compromise
secrecy and new participants can be added or existing participants
removed from the group.
Paragraph (version A):
The "transcript" field contains the list of "GroupOperation"
messages that led to this state.
Paragraph (version B):
The "transcript_hash" field contains the list of "GroupOperation"
messages that led to this state.
Paragraph (version A):
When a new one-member group is created (which requires no
GroupOperation), the "transcript_hash" field is set to an all-zero
vector of length Hash.length.
Paragraph (version B):
When a new one-member group is created (which requires no
GroupOperation), the "transcript_hash" field is set to an all-zero
vector of length Hash.length, where the Hash algorithm is defined by
the ciphersuite.
Paragraph (version A):
Use the "confirmation_key" for the new group state to compute the
finished MAC for this message, as described below, and verify that
it is the same as the "finished_mac" field.
Paragraph (version B):
Use the "confirmation_key" for the new group state to compute the
"confirmation" MAC for this message, as described below, and
verify that it is the same as the "confirmation" field.