[MLS] Thoughts on draft-ietf-mls-pq-ciphersuites

[Soatok Dreamseeker <[e-mail]>]

Good afternoon,

I'm working on a few projects that intersect with MLS in interesting ways.
The most pertinent of which is a key transparency project for the Fediverse
which I hope will enable the secure bootstrapping of public keys for use in
end-to-end encryption (which should, in turn, use MLS).

You can learn about this project here:

1. https://publickey.directory
2.
https://soatok.blog/category/technology/open-source/fediverse-e2ee-project/

The actual E2EE on ActivityPub folks (mostly W3C or W3C-affiliated) are
coordinating their efforts on GitHub. In January, I opened a discussion
recommending specific MLS ciphersuites here:
https://github.com/swicg/activitypub-e2ee/issues/59

In recent weeks, Google and Cloudflare have both announced a 2029 timeline
to adopt post-quantum cryptography everywhere. After talking with some
folks at RWC 2026, and seeing those announcements, I'm planning to update
my proposal to migrate to ML-DSA-44 instead of Ed25519 for my key
transparency work. Ideally, we'd also be able to use ML-DSA-44 for the
ActivityPub E2EE work as well.

However, the current draft is incompatible with my goals. Notably:

1. No ChaCha20-Poly1305 ciphersuites
2. ML-DSA-87 is in the current draft, but -44 is not.

I specifically need ChaPoly because I am implementing this in languages and
runtimes without access to a native cryptography implementations or raw
Assembly, and may be running on hardware without hardware-accelerated AES,
and I trust myself to implement ChaCha20 and Poly1305 in constant-time, but
I am worried about JIT compilers and VM optimizations undermining my
attempts to make the AES S-box constant-time.

I recall there were some concerns over the ML-KEM-512 parameter set being
too close to the security margin for comfort, which motivated the
prioritization of ML-KEM-768. A similar concern was not present for ML-DSA,
and the -44 parameter set is considered secure with sufficient margin to
not invite the same kind of bikeshedding discussions that ML-KEM-512
provoked. For this reason, I do not feel that the -65 or -87 security
levels are required for my purposes, and  therefore cannot the bandwidth
costs for the larger parameter sets.

I am ambivalent about hash functions. SHA-256, SHA-384, SHA-512, BLAKE2b,
BLAKE3, SHA3-256, SHA3-384, SHA3-512, KangarooTwelve. These are all secure
enough for my purposes. Given the widespread availability of SHA2, my
default choice will be SHA512 or SHA384 (since they're both fast on 64-bit
hardware).

I acknowledge that asking for the draft be expanded to include a few
additional options risks a combinatorial explosion of combinations, so I
will instead ask for one ciphersuite be added to the list that includes
both ChaCha20-Poly1305 and ML-DSA-44. That is to say:

MLS_X_MLKEM768X25519_CHACHA20POLY1305_SHA384_MLDSA44

Where X is either 128 (conservative) or 192 (which seems more appropriate
to me, given that the security of the KEM is >= 192 bits, the AEAD is 256
bits, and the hash function's birthday bound is about 192 bits).

Thanks for taking the time to consider my request.

Kind regards,
Soatok