Section 17.2 about mls-protocol

[Bren2010]

I remember arguing that the FIPS suite should be MTI at one of the interims. The argument (iirc) was that people that need FIPS are going to implement FIPS anyways, so the MTI should be the one that's subjectively / widely-considered best. "But then wouldn't a FIPS-only client not conform to the RFC?" Yes, but the people that require FIPS will not care.

[paulwouters]

Well I know from IKEv2/IPsec, that we do take this into account and do ensure there is only FIPS MITM.
I also know we are discussing this in openpgp and also for that reason are adding AES_GCM there.

So if the only reasoning is "FIPS will force people to break RFCs anyway", that's kinda weak :P

[bifurcation]

... do ensure there is only FIPS MITM

You mean "MTI"? I don't think the MITM folks care about FIPS :)

I think @Bren2010's summary captures the state of the art pretty well. Note as well that X25519 and Ed25519 are slated for inclusion in the relevant FIPS standards, so this will soon be moot anyway. (For some government-speed definition of "soon".) So yes, some FIPS folks might be sad in the short run, but things will even out.

The working group had a robust discussion on this, and landed on this as a compromise that could get consensus. I don't think these FIPS concerns are worth upsetting that consensus.

[rohan-wire]

Realistically, most folks using end-to-end encrypted instant messaging today are already using a variation of the DoubleRatchet protocol, using Ed25519. Many of our largest customers normally use FIPS, but have exceptions to use Ed25519 in this context and have no problem using Ed25519 for MLS.

[paulwouters]

(yes MTI :)

That NIST doc is from 2017, so I"m not sure what you mean with "soon" :)

I personally think it should be fixed but won't block it. Let's see what the IESG says though :)