Change:
KeyPackage publication system SHOULD rate-limit KeyPackage requests, especially if not authenticated. <del> 15.6. </del> <ins> 15.7. </ins> It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath

Discussion:
I would propose we say that we need AE1 security for our AEAD scheme, which gives us random ciphertexts and if we have random ciphertexts the input to key/nonce generation for sender data encryption is unique. This in turn gives us AE1 security for sender data encryption. I don't think we need AE2 encryption because our nonces are random and don't reveal any private information. Also, if I understand correctly, AES GCM is not AE2 secure, so if we want AE2 security, we need a different scheme or the transform described in NAN. Probably needless to say, but I don't have a security proof for any of this. So more eyes on whatever we write here would be appreciated.
Comment by NAME I don't think I understand the security model here? What happens if the previous ciphertext has 00's for the first KDF.Nh bytes?
The ciphertext sample here is just acting as a salt to produce several distinct key/nonce pairs from a single . So as with , all-zeros isn't inherently harmful here, unless it happens repeatedly. (Note that this scheme was inspired by , except the latter only uses 16 bytes of sample and XOR instead of AEAD.) If the content encryption is done properly, then the probability of any particular value is vanishingly small, due to the ciphertext looking like random data. Someone could construct a ciphertext that results in nonce reuse, e.g., having the same bytes as a previous message. However, note that the harm here is done when the reused key/nonce is used to encrypt and the encrypted sender info is published to the attacker. This means that the attack cannot be mounted from outside the group. Even if the attacker can cause a sender to encrypt a given plaintext, the attacker would not know the key with which it would be encrypted. So the best attack is for an insider to the group to leak the sender info. cc NAME who did some analysis on this IIRC
I didn't do analysis on this, however I'm a bit concerned by the assertion "due to the ciphertext looking like random data". I don't think this is a standard security assumption we do on AEADs? For example if I take a secure AEAD, and build a new one by prefixing zeroes, the new AEAD is as secure as the original one?

To make sure that there is no key/nonce re-use, I think it would be better to use a full hash on the ciphertext, but it increases computation cost.
Yeah, I'm also a bit wary of this assumption. I think this would correspond to -IND-CCA security for the AEAD scheme. Wasn't this inspired by QUIC somehow (maybe header encryption)? In any case, if we don't do so already, we might want to explicitly note this in the ciphersuite section to ensure that AEAD schemes added in the future indeed produce pseudorandom ciphertexts.
It also occurs to me that is only 12 bytes long (and 12 < 16), so we could change this to literally do what QUIC does: (And there's a parallel for ChaCha) That would more clearly benefit from any QUIC analysis, and would save an extra auth tag. It would be a minor pain to implement, because you would need access to a raw cipher as well as an AEAD mode.
It looks like it also relies on the ciphertext prefix being random? I dislike this approach which is too low-level in my opinion, I would prefer staying with high-level cryptographic primitives.
I filed to try to address this. Basically, I argue that the same arguments from Bellare et al. that apply to QUIC header protection also apply here. The PR also adds a requirement that AEADs act as PRFs, as discussed here.