Change:
cc NAME
Quick question without reading much, but why can'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 didn'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 won't need to change this, and we'll have basically the minimum amount of fresh entropy needed.
Nope you can'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 !
NAME 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 won'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 doesn'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
NAME NAME I don't have a strong opinion here, I was just pointing that we already has a fresh value. I can see why Brendan 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.
Denis Jackson 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.
NAME 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!

Discussion:
verify Sender.sender_type is "member" and use Sender.sender for MLSSenderData.sender. <ins> 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. </ins> The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely:

sender) application key chain for the current epoch, according to the type of message being encrypted. <ins> 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. 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. </ins> The Additional Authenticated Data (AAD) input to the encryption contains an object of the following form, with the values used to identify the key and nonce: