Draft: draft-ietf-mls-protocol

Commentary: cc 
 Quick question without reading much , but why ca n't we reuse the sender data nonce which is always fresh to do this ? 
 You could do that ; in fact you could just use that nonce for the content encryption as well as the sender data encryption , and forget about the key - schedule derived nonces as well . The reason I did n't go down that path is that I 'm generally leery of requiring fresh randomness in the protocol . In particular , for the sender data , I think we should be moving toward masking instead of GCM ( cf ) . If we do masking , then we wo n't need to change this , and we 'll have basically the minimum amount of fresh entropy needed . 
 Nope you ca n't really do that . The xoring of the two is strictly stronger , even if your PRNG is bad , you 'll benefit from the entropy of the deterministic nonce because of the current epoch secret to which many people have contributed to . Until we do that move to masking , I think I would prefer to have the xor use the sender data nonce . 
 I 'm confused about what you 're talking about . In the current proposal : I agree that that 's better than just using the for the reasons you say . But I thought what you were proposing was : Either way , we 're incorporating the key schedule nonce . How about the following proposal ? For now : If we do masking later , we do something like what 's in this PR 
 Works for me ! 
 if the revised scheme looks ok to you , I 'll consider this ready to merge 
 If I had a concern with the new scheme , it 's that it 's no longer resistant to nonce misuse . For example , consider somebody setting . 
 That would violate the requirement that the be fresh . I 've clarified that requirement in the latest commit . 
 Putting a requirement in the spec is good . But that wo n't stop a nonce - misusing implementation from running , which was the point of deterministically generating the nonce in the first place . 
 I 'm not sure why you think a freshness requirement is less plausible for the than for the . Neither is enforceable in the protocol . ! 
 The value of is that it 's only 4 bytes , so it does n't mask the whole thing . Worst case , can reliably fix 32 bits , leaving only 64 bits of actual randomness in the nonce . Not good , but better than 0 , and better than invoking a hash to actually mix things . 
 The fact that is not called a nonce and is a different size also makes me feel better about it not being misused 
 I do n't have a strong opinion here , I was just pointing that we already has a fresh value . I can see why  prefers the smaller guard using a fresh distinct value , so I 'll support this or any variant for which you both agree ; ) 
 Reverted to the approach , which it seems everyone is OK with . 
 Earlier , we had considered a " masking " approach for sender data , much like QUIC does for . This approach would save 28 bytes of overhead ( nonce + tag ) , but was abandoned because of uncertainty around the security of the masking approach . Since then , Bellare et al . published , which includes what is effectively a proof of the security properties of the QUIC scheme . The QUIC scheme is essentially scheme HN1 of the paper , the main difference being that QUIC encrypt not the nonce directly , but a packet number which is used to compute the nonce . Our application would be similar , since we would encrypt metadata used to encrypt the key and the nonce . Given this new analysis , is it time to bring back masking ? 
 Fixed by 
 Nonces and keys are generated deterministically . If a client 's state is rolled back to a previous version ( because the process crashed , for instance ) , then the client is very likely to re - use the same key+nonce pair to encrypt a different application message . This breaks the confidentiality of the AEAD . Consider using explicit nonces ( even small ones will do ) or SIV - like constructions . 
   already discussed this , the WG , including I , was pretty conservative at the time but I am feeling more and more we should do it , indeed … There are other linked problems that I ’ll discuss today but in general , in case of recoverable state loss I would strongly favor mandating an update which would definitely help with the problem . Detecting such losses is probably not trivial though :) B. 
 Notes for reference : The other solution we thought about was using the fresh explicit nonce as a re - randomizing solution for the deterministic handshake nonce . 
 Approved . This is perfect ! Thanks !
Paragraph (version B):
The "reuse_guard" field contains a fresh random value used to avoid
nonce reuse in the case of state loss or corruption, as described in
content-signing-and-encryption.
Paragraph (version B):
Before use in the encryption operation, the nonce is XORed with a
fresh random value to guard against reuse.  Because the key schedule
generates nonces deterministically, a client must keep persistent
state as to where in the key schedule it is; if this persistent state
is lost or corrupted, a client might reuse a generation that has
already been used, causing reuse of a key/nonce pair.
Paragraph (version B):
To avoid this situation, the sender of a message MUST generate a
fresh random 4-byte "reuse guard" value and XOR it with the first
four bytes of the nonce from the key schedule before using the nonce
for encryption.  The sender MUST include the reuse guard in the
"reuse_guard" field of the sender data object, so that the recipient
of the message can use it to compute the nonce to be used for
decryption.