Draft: draft-ietf-mls-protocol

Commentary: 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 . 
 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 do n'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 : do n'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 do n'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 is n'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 was n'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 : extension should n't be allowed to contain GREASE codepoints even though all members may " support " that codepoint types that are GREASE should n't be allowed to be sent even though all members may " support " that proposal type codepoints should n'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 do n't there is an obvious translation because MLS is fundamentally a clients - to - clients protocol instead of a client - to - server protocol . 
 Grease is n'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 wo n't break a group because receivers ignore cipher suites they do n'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
Paragraph (version B):
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.
Paragraph (version A):
The "capabilities" field indicates what protocol versions,
ciphersuites, extensions, credential types, and non-default proposal
types are supported by a client.  Proposal and extension types
defined in this document are considered "default" and thus need not
be listed, while any credential types the application wishes to use
MUST be listed.  Extensions that appear in the "extensions" field of
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"
field.
Paragraph (version B):
The "capabilities" field indicates what protocol versions,
ciphersuites, extensions, credential types, and non-default proposal
types are supported by a client.  Proposal and extension types
defined in this document are considered "default" and thus need not
be listed, while any credential types the application wishes to use
MUST be listed.  Extensions that appear in the "extensions" field of
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"
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.
Paragraph (version A):
Extension included in the "extensions" or "leaf_node.extensions"
fields MUST be included in the "leaf_node.capabilities" field.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
A client initiating a group MUST ignore all unrecognized
ciphersuites, extensions, and other parameters.  Otherwise, it may
fail to interoperate with newer clients.
Paragraph (version B):
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.
Paragraph (version B):
A client processing a GroupInfo object MUST ignore all
unrecognized extensions in the "extensions" field.
Paragraph (version A):
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
group.
Paragraph (version A):
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.
Paragraph (version A):
The parameters of a group may be changed by sending a
GroupContextExtensions proposal to enable additional extensions, or
by reinitializing the group as described in reinitialization.
Paragraph (version B):
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
group.
Paragraph (version B):
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.
Paragraph (version B):
The parameters of a group may be changed by sending a
GroupContextExtensions proposal to enable additional extensions
(groupcontextextensions), or by reinitializing the group
(reinitialization).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.