Original text:
framing.  Security notions such as forward secrecy and post- compromise security are defined in security-considerations.  2.1. We use the TLS presentation language RFC8446 to describe the 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>  The "leaf_node_source" field indicates how this LeafNode came to be added to the tree.  This signal tells other members of the group The field "leaf_node.leaf_node_source" of the LeafNode in a KeyPackage MUST be set to "key_package". <del> Extension included in the "extensions" or "leaf_node.extensions" fields MUST be included in the "leaf_node.capabilities" field. </del>  10.1. creator of a GroupInfo may recompute the confirmation tag as "MAC(confirmation_key, confirmed_transcript_hash)".)  New members MUST verify that "group_id" is unique among the groups they're currently participating in. advertised in it.  Otherwise, another client might fail to interoperate by selecting one of those parameters. <del> A client initiating a group MUST ignore all unrecognized ciphersuites, extensions, and other parameters.  Otherwise, it may fail to interoperate with newer clients. </del>  Any field containing a list of extensions MUST NOT have more than one extension of any given type. extensions.  The "capabilities" field MUST indicate support for each extension in the GroupContext. <del> If any extension in a GroupInfo message is unrecognized (i.e., not contained in the "capabilities" of the corresponding KeyPackage), then the client MUST reject the Welcome message and not join the </del>  group. <del> Note that the latter two requirements mean that all MLS extensions are mandatory, in the sense that an extension in use by the group MUST be supported by all members of the group. </del>  The parameters of a group may be changed by sending a <del> GroupContextExtensions proposal to enable additional extensions, or by reinitializing the group as described in reinitialization. </del>  14.

Reviewer comments:
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

Revised text:
framing.  Security notions such as forward secrecy and post- compromise security are defined in security-considerations. <ins> As detailed in grease, MLS uses the "Generate Random Extensions And Sustain Extensibility" (GREASE) approach to maintaining extensibility, where senders insert random values into fields in which receivers are required to ignore unknown values.  Specific "GREASE values" for this purpose are registered in the appropriate IANA registries. </ins> 2.1. We use the TLS presentation language RFC8446 to describe the 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"  <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 The field "leaf_node.leaf_node_source" of the LeafNode in a KeyPackage MUST be set to "key_package".  <ins> Extensions included in the "extensions" or "leaf_node.extensions" fields MUST be included in the "leaf_node.capabilities" field.  As discussed in extensibility, unknown extensions in "KeyPackage.extensions" MUST be ignored, and the creator of a "KeyPackage" object SHOULD include some random GREASE extensions to help ensure that other clients correctly ignore unknown extensions. </ins> 10.1. creator of a GroupInfo may recompute the confirmation tag as "MAC(confirmation_key, confirmed_transcript_hash)".) <ins> As discussed in extensibility, unknown extensions in "GroupInfo.extensions" MUST be ignored, and the creator of a "GroupInfo" object SHOULD include some random GREASE extensions to help ensure that other clients correctly ignore unknown extensions. Extensions in "GroupInfo.group_context.extensions", however, MUST be supported by the new joiner. </ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in. advertised in it.  Otherwise, another client might fail to interoperate by selecting one of those parameters.  <ins> A client processing a KeyPackage object MUST ignore all unrecognized values in the "capabilities" field of the "LeafNode", and all unknown extensions in the "extensions" and "leaf_node.extensions" fields.  Otherwise, it could fail to interoperate with newer clients. A client processing a GroupInfo object MUST ignore all unrecognized extensions in the "extensions" field. </ins> Any field containing a list of extensions MUST NOT have more than one extension of any given type. extensions.  The "capabilities" field MUST indicate support for each extension in the GroupContext.  <ins> A client joining a group MUST verify that it supports every extension in the GroupContext for the group.  Otherwise, it should treat the enclosing GroupInfo message as invalid and not join the </ins> group.  <ins> Note that the latter two requirements mean that all MLS GroupContext extensions are mandatory, in the sense that an extension in use by the group MUST be supported by all members of the group. </ins> The parameters of a group may be changed by sending a  <ins> GroupContextExtensions proposal to enable additional extensions (groupcontextextensions), or by reinitializing the group (reinitialization). 13.5. As described in extensions, clients are required to ignore unknown values for certain parameters.  To help ensure that other clients implement this behavior, a client can follow the "Generate Random Extensions And Sustain Extensibility" or GREASE approach described in RFC8701.  In the context of MLS, this means that a client creating a LeafNode or Welcome message includes random values in certain fields, which should be ignored by a correctly-implemented client processing the message.  A client that incorrectly rejects unknown code points will fail to process such a message, providing a signal to its implementer that the client needs to be fixed. When generating the following fields, an MLS client SHOULD include a random selection of values chosen from these GREASE values: "LeafNode.capabilities.versions" "LeafNode.capabilities.ciphersuites" "LeafNode.capabilities.extensions" "LeafNode.capabilities.proposals" "LeafNode.capabilities.credentials" "KeyPackage.extensions" "GroupInfo.extensions" For the KeyPackage and GroupInfo extensions, the "extension_data" for GREASE extensions MAY have any contents selected by the sender, since they will be ignored by a correctly-implemented receiver.  For example, a sender might populate these extensions with a randomly- sized amount of random data. A set of values reserved for GREASE have been registered in the various registries in iana-considerations.  This prevents conflict between GREASE and real future values.  The following values are reserved in each registry: "0x0A0A", "0x1A1A", "0x2A2A", "0x3A3A", "0x4A4A", "0x5A5A", "0x6A6A", "0x7A7A", "0x8A8A", "0x9A9A", "0xAAAA", "0xBABA", "0xCACA", "0xDADA", and "0xEAEA".  (The value "0xFAFA" falls within the private use range.)  These values MUST only appear in the fields listed above, and not, for example, in the "proposal_type" field of a Proposal.  Clients MUST NOT implement any special processing rules for how to handle these values when receiving them, since this negates their utility for detecting extensibility failures.  GREASE values MUST be handled using normal logic for processing unsupported values.  When comparing lists of capabilities to identify mutually-supported capabilities, clients MUST represent their own capabilities with a list containing only the capabilities actually supported, without any GREASE values.  In other words, lists including GREASE values are only sent to other clients; representations of a client's own capabilities MUST NOT contain GREASE values. </ins> 14.