Comments (10)
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
, andcredentials
fields ofCapabilities
- The
extensions
fields ofKeyPackage
andGroupInfo
(which are effectively ephemeral), with random extension data
- The
from mls-protocol.
@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?
from mls-protocol.
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.
from mls-protocol.
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.
from mls-protocol.
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.
from mls-protocol.
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
RequiredCapabilities
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.
from mls-protocol.
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.
from mls-protocol.
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.
from mls-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.
from mls-protocol.
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.
from mls-protocol.
Related Issues (20)
- Section 17.6
- Section 10.2 HOT 2
- Section 12 HOT 7
- Section 13.2 HOT 3
- Discuss metadata privacy HOT 3
- Section 15.3 HOT 2
- Citations to security analysis HOT 4
- Section 16.2 HOT 2
- Section 17.1 HOT 2
- Section 17.2 HOT 5
- Nits HOT 1
- Clarify that AS needs to see both signature key and credential
- Create an IANA registry for WireFormat values HOT 1
- Faster remove? HOT 24
- IANA considerations for signature labels? HOT 2
- Change log missing for -16 and -17
- Loosen chain requirements HOT 5
- Figure 14: "Derivation of ratchet tree keys along a direct path" don't correspond to the prose HOT 1
- Minor problem in transcript hash message formats HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mls-protocol.