Change:
a LeafNode MUST be included in the "extensions" field of the "capabilities" field, and the credential type used in the LeafNode MUST be included in the "credentials" field of the "capabilities" <del> field. </del> <ins> field.  As discussed in extensibility, unknown values in "capabilities" MUST be ignored, and the creator of a "capabilities" field SHOULD contain some random GREASE values to help ensure that other clients correctly ignore unknown values. </ins> The "leaf_node_source" field indicates how this LeafNode came to be added to the tree.  This signal tells other members of the group

Discussion:
This PR is an attempt to address . It registers GREASE code points in the relevant registries and recommends their use in the appropriate places. It also includes some edits to the extensibility provisions to make them clearer and sharper, and a little cleanup on registry formatting.
(First off, I know that I'm super late in the process so feel free to tell me to go away and I'll do that.) I see that MLS is creating . I think it would benefit the protocol to reserve a few codepoints from all of these registries for . That'll help avoid ossification down the line.
NAME How would this work in MLS. In GREASE the client proposes values to a server (which the server should never support). The client is expected to propose these values and also reject them. This works fine because clients don't talk to clients. In MLS, clients send messages directly to other clients, and create groups based on capabilities advertised in KeyPackages. How would you prevent a "dummy" ciphersuite or version number from being used in an MLS group?
The GREASE RFC is specific to TLS where extensions are client-initiated, but the concept applies anywhere and is not specific to client-server protocols. To support GREASE, all we need is: reserve some codepoints in the IANA registry to avoid future collisions when sender sends its list of supported values, it randomly adds a value from the GREASE set no changes are made on the receiver Because of this, the receivers will ignore the GREASE codepoints and there is no risk of negotiating them. Another way to say this is: don't implement GREASE by adding the codepoints to your supported set, instead only add a random one from your send serialization code.
Some thoughts: I think we expect many/most MLS deployments to be single-party, where the same organization controls the client and server software. As such, GREASE has less value than in a TLS context, because if that organization wants to exercise a new extension point they can easily correct any errors in their software that would prevent them from doing so. MLS is also expected to be layered on top of an encrypted transport protocol, which prevents third-party meddling to begin with.

On a more philosophical note -- If GREASE is supposed to prevent poorly maintained client software or middleware from breaking the protocol when extension points are exercised that they don't understand, then does it really still work if GREASE is a core part of the protocol? If the semantic of some field in the protocol is that unexpected values should be ignored, it seems just as easy for a negligent engineer to write the code "break if there's something besides X, Y, or Z" as it is to write "break if there's something besides X, Y, Z, or one of the GREASE codepoints". Correspondingly, I'm not sure that we have historical validation from TLS that GREASE works.
We have some solid validation from HTTP that grease works. In both HTTP/2 and HTTP/3, receivers are supposed to ignore unknown frames. HTTP/2 was launched without grease, and trying to use extensions caused enough breakage that they had to be removed. HTTP/3 launched with grease, and a few implementations send random data, so broken servers were found and fixed before they got prevalent. Regarding the philosophical point, grease isn't meant to avoid malicious implementors - you can always write code that looks at grease. Grease is meant to avoid lazy implementors, of which we have solid existence proofs.
Right, I wasn't thinking of malicious implementors, just negligent ones. There are places where the "receiver" portion of an MLS client does need to be aware of GREASE. These immediately come to mind: A extension shouldn't be allowed to contain GREASE codepoints even though all members may "support" that codepoint Proposal types that are GREASE shouldn't be allowed to be sent even though all members may "support" that proposal type GREASE codepoints shouldn't be considered when deciding whether a group uses the "best" version & ciphersuite for all members, as one of these codepoints may naively look "better" than a real one These would all seem to carry the risk of accidentally writing the code I said earlier, "break if there's something besides X, Y, Z, or one of the GREASE codepoints" because GREASE is being intentionally excluded before those other checks happen. Fwiw, I'm not against this idea, I'm just not sure of the right way to translate it to MLS.

That's not right, the whole point of grease is for it to not modify receiver code. No one ever "supports" grease code points, they just randomly send them. Since receiving an unknown value in would break a group, then we definitely should not send grease in that scenario. Determining the "best" version/ciphersuite/etc requires first making the intersection set of supported versions, and grease would never be in that set since no one "supports" grease code points.
If that is the case, then it seems you have eliminated all the places you might have used GREASE. I don't there is an obvious translation because MLS is fundamentally a clients-to-clients protocol instead of a client-to-server protocol.
Grease isn't about clients or servers, it's about senders and receivers - which MLS has. When a clients sends its capabilities, it can for example grease the list of cipher suites - that won't break a group because receivers ignore cipher suites they don't support.
Another way to think about this: you can (and should) grease anything where recipients ignore unknown/unrecognized values. So for MLS, I'd base the list off of this text:
Just to make this a little more concrete, I think that this is the text we would want GREASE around: So a PR would basically do the following: Register GREASE values for ciphersuites, extension types, proposal types, credential types Recommend that clients include a random selection of GREASE values in: The , , , and fields of The fields of and (which are effectively ephemeral), with random extension data