Two related observations after reading foundation/mls-protocol.md and app-components/account-identity-proof-v2.md. Happy to turn either into a PR if useful, but the foundation surface looked like something to discuss before touching.
1. The mandatory ciphersuite is classical, and MLS's guarantees don't cover the gap.
MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 is classical throughout. MLS gives forward secrecy and post-compromise security, but both are guarantees about key compromise over time. Neither helps against an adversary who records ciphertext today and breaks X25519 later. Group history recorded now is decryptable in full once the DH assumption falls, however many times the group has rekeyed.
That profile, long-lived and high-volume with many participants' data concentrated in one place, is exactly what makes retroactive decryption worth an adversary's storage budget.
Separately, and independently of the quantum question: a 128-bit suite with AES-128/SHA-256 sits below the AES-256/SHA-384 floor CNSA 2.0 requires for long-term confidentiality, and Australia's ISM withdraws approval for AES-128 and SHA-256 after 2030.
2. A post-quantum ciphersuite would not, on its own, make Marmot post-quantum.
This is the part I'd most like a second opinion on. foundation/identity.md establishes that a Marmot account identity is a Nostr x-only secp256k1 key, and account-identity-proof-v2 binds that account to an MLS leaf with a BIP-340 Schnorr signature over a NIP-01 event.
That signature is the root of trust for group membership. An adversary who recovers an account's secp256k1 private key, which Shor does from the published pubkey and every Nostr pubkey is published, can mint a valid identity proof authorizing an MLS signature key they control, and be added to a group as that member.
So even adopting MLS_256_MLKEM1024_AES256GCM_SHA384_MLDSA87 would leave the MLS layer post-quantum and the door into it classical. I don't think that's a reason to delay the ciphersuite work, since the KEM protects recorded traffic retroactively and so has to be deployed before the break, whereas identity forgery is a live-attack problem. But it seemed worth stating in the spec rather than letting a PQ ciphersuite imply an end-to-end guarantee.
On what to actually change: probably not the mandatory ciphersuite. A group can only use a suite supported by every member and every KeyPackage, so changing the MUST breaks interop for no immediate gain, and migration is gated by the slowest member. The thing that can land now is capability advertisement, so groups can negotiate upward the moment every member qualifies.
draft-ietf-mls-pq-ciphersuites-04 (MLS WG, 19 March 2026) defines the candidates. Note their code points are still TBD, since IANA hasn't assigned values, so any reference would have to be by name for now, and I'd assume you wouldn't want provisional numbers in foundation/registries.md.
For context on the identity half of this, we've been working on deriving post-quantum keys from the NIP-06 seed as siblings of the secp256k1 key, so that breaking secp256k1 doesn't yield them. It is implemented and running against public relays if it is useful as prior art: https://nostr-wot.com/pqc/chat and the write-up at https://quantakrypto.com/blog/post-quantum-identity-keys-for-nostr
Questions: does Marmot want to raise the symmetric floor to AES-256/SHA-384 independently of any of this? And is there an existing convention for referencing not-yet-assigned external code points?
Two related observations after reading
foundation/mls-protocol.mdandapp-components/account-identity-proof-v2.md. Happy to turn either into a PR if useful, but the foundation surface looked like something to discuss before touching.1. The mandatory ciphersuite is classical, and MLS's guarantees don't cover the gap.
MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519is classical throughout. MLS gives forward secrecy and post-compromise security, but both are guarantees about key compromise over time. Neither helps against an adversary who records ciphertext today and breaks X25519 later. Group history recorded now is decryptable in full once the DH assumption falls, however many times the group has rekeyed.That profile, long-lived and high-volume with many participants' data concentrated in one place, is exactly what makes retroactive decryption worth an adversary's storage budget.
Separately, and independently of the quantum question: a 128-bit suite with AES-128/SHA-256 sits below the AES-256/SHA-384 floor CNSA 2.0 requires for long-term confidentiality, and Australia's ISM withdraws approval for AES-128 and SHA-256 after 2030.
2. A post-quantum ciphersuite would not, on its own, make Marmot post-quantum.
This is the part I'd most like a second opinion on.
foundation/identity.mdestablishes that a Marmot account identity is a Nostr x-only secp256k1 key, andaccount-identity-proof-v2binds that account to an MLS leaf with a BIP-340 Schnorr signature over a NIP-01 event.That signature is the root of trust for group membership. An adversary who recovers an account's secp256k1 private key, which Shor does from the published pubkey and every Nostr pubkey is published, can mint a valid identity proof authorizing an MLS signature key they control, and be added to a group as that member.
So even adopting
MLS_256_MLKEM1024_AES256GCM_SHA384_MLDSA87would leave the MLS layer post-quantum and the door into it classical. I don't think that's a reason to delay the ciphersuite work, since the KEM protects recorded traffic retroactively and so has to be deployed before the break, whereas identity forgery is a live-attack problem. But it seemed worth stating in the spec rather than letting a PQ ciphersuite imply an end-to-end guarantee.On what to actually change: probably not the mandatory ciphersuite. A group can only use a suite supported by every member and every KeyPackage, so changing the MUST breaks interop for no immediate gain, and migration is gated by the slowest member. The thing that can land now is capability advertisement, so groups can negotiate upward the moment every member qualifies.
draft-ietf-mls-pq-ciphersuites-04(MLS WG, 19 March 2026) defines the candidates. Note their code points are stillTBD, since IANA hasn't assigned values, so any reference would have to be by name for now, and I'd assume you wouldn't want provisional numbers infoundation/registries.md.For context on the identity half of this, we've been working on deriving post-quantum keys from the NIP-06 seed as siblings of the secp256k1 key, so that breaking secp256k1 doesn't yield them. It is implemented and running against public relays if it is useful as prior art: https://nostr-wot.com/pqc/chat and the write-up at https://quantakrypto.com/blog/post-quantum-identity-keys-for-nostr
Questions: does Marmot want to raise the symmetric floor to AES-256/SHA-384 independently of any of this? And is there an existing convention for referencing not-yet-assigned external code points?