Draft: draft-ietf-mls-protocol

Commentary: This PR fixes a few small issues I noticed while reviewing mlspp for compliance with the spec : The size of the vector needs to expand to support trees for large groups The content of the extension is specified is included in so that it goes into the transcript now carries an even though the value is always present , so that the transcript matches the data on the wire 
 Discussed at Interim . Merge 
 In the current protocol draft : Unless I overlooked it , the current draft seems to be also missing a " simple " DoS case where a handshake message could omit / malform some ( e.g. by having an empty ciphertext or invalid kem_output ) -- this should be easily detectable ( either by members themselves or if handshake messages are transmitted as MLSPlaintext , the delivery service could reject that ) . For that originally discussed case , I guess the sketched out solution with a " Nack " message containing a DLEQ proof could work . Besides the drawbacks described there , one will also need to extend HPKE definitions to allow for this " directly decrypt from the revealed shared secret " use case . 
 You 're correct that there is a simpler DoS case where the sender could simply send a malformed . It shares with the DoS described that it is only detectable by affected nodes . And I think that those two together cover the DoS possibilities , since it covers the two things that can be chosen in Commit . As far as Nack / DLEQ -- I 'm not sure what you have in mind there . It seems like you would want zero - knowledge proofs for two relationships between HPKE ciphertexts : ( 1 ) that two ciphertexts are encryptions of the same value under two different public keys , and ( 2 ) that a parent ciphertext is an encryption of the parent   , and the child ciphertext is an encryption of the child node secret . It 's not clear that there are solutions for either of these . What we can do though , is make sure that the Security Considerations cover these risks . I would propose focusing on documenting the risk rather than fixing it . 
 For that simpler case , it can be detected by other nodes by doing extra checks ( e.g. checking all cipher text lengths or public key formats match what one would expect in a particular ciphersuite ) . I was referring to the final comments here : So , the goal wo n't be to prevent malicious insiders , but allow affected nodes to report that they could n't process Commit by revealing the corresponding ephemeral key . With HPKE / current draft , it may be : for malformed path secrets , affected nodes reveal + others check DLEQ ; then using compute for and can go ahead to check the path secrets ( either the ciphertext is malformed or the public keys derived from secrets do n't match the received public keys in Commit ) 
 Discussed on virtual interim 2020 - 10 - 20 : Closing pending a more detailed proposal . 
 At a minimum we need to make handshake key chains . If we do Proposals ( ) , then we will need to encrypt multiple handshake message per epoch , so we will need key chains instead of just a single handshake key . Even if we do n't do , this would improve symmetry / code reuse . Specifically , we should repurpose the ASTree " per - user secret tree " . Instead of the leaves of the tree being the starting point for an application key chain , there would be used to derive the starting points for the application key chain , handshake key chain , and possibly exported per - user secrets . 
 This ended up not being necessary . For handshake messages , we do n't need forward secrecy within an epoch , so the full AStree machinery is n't necessary . Instead we use the simple TLS - like nonce updating described in
Paragraph (version B):
The "parent_hash" extension carries information to authenticate the
structure of the tree, as described below.