Consider greasing your registries

[DavidSchinazi]

(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 8 new IANA registries. I think it would benefit the protocol to reserve a few codepoints from all of these registries for GREASE. That'll help avoid ossification down the line.

[rohan-wire]

@DavidSchinazi 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?

[DavidSchinazi]

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.

[Bren2010]

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.

[DavidSchinazi]

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.

[Bren2010]

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:

1. A RequiredCapabilities extension shouldn't be allowed to contain GREASE codepoints even though all members may "support" that codepoint
2. Proposal types that are GREASE shouldn't be allowed to be sent even though all members may "support" that proposal type
3. 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.

[DavidSchinazi]

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 RequiredCapabilities 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.

[rohan-wire]

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 RequiredCapabilities 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.

[DavidSchinazi]

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.

[DavidSchinazi]

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: A client initiating a group MUST ignore all unrecognized ciphersuites, extensions, and other parameters. Otherwise, it may fail to interoperate with newer clients.

[bifurcation]

Just to make this a little more concrete, I think that this is the text we would want GREASE around:

A client initiating a group MUST ignore all unrecognized ciphersuites, extensions, and other parameters

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 ciphersuites, extensions, proposals, and credentials fields of Capabilities
  • The extensions fields of KeyPackage and GroupInfo (which are effectively ephemeral), with random extension data