Add handling and helpers for GREASE values #1900
Conversation
franziskuskiefer
left a comment
franziskuskiefer
left a comment
There was a problem hiding this comment.
Just leaving a request changes here to reflect the discussion on Zulip.
erskingardner
force-pushed
the
grease
branch
from
85a51f4 to
9ee8d5a
Compare
erskingardner
changed the title
|
@franziskuskiefer any chance you can have a look here to see if the changes I've made are more in line with what we talked about? |
…ndom GREASE values into capabilities. Update documentation to clarify GREASE handling and ensure users opt-in for GREASE value inclusion. Adjust tests to reflect changes in GREASE injection behavior.
franziskuskiefer
force-pushed
the
grease
branch
from
288c086 to
a17c48a
Compare
franziskuskiefer
left a comment
franziskuskiefer
left a comment
There was a problem hiding this comment.
Happy new year 🍾
Thanks for the changes. lgtm now with two nits.
| - [#1868](https://github.com/openmls/openmls/pull/1868): Implemented AppEphemeral functionality as defined in the MLS Extensions draft and replaced the existing AppAck proposal with the AppAck object, which can now be conveyed inside an AppEphemeral proposal. These features are behind the `extensions-draft-08` feature flag. | ||
| - [#1874](https://github.com/openmls/openmls/pull/1874): In the `openmls_libcrux_crypto` provider, added AES-GCM support. | ||
| - Implemented GREASE (Generate Random Extensions And Sustain Extensibility) support as defined in [RFC 9420 Section 13.5](https://www.rfc-editor.org/rfc/rfc9420.html#section-13.5): | ||
| - Added `Grease(u16)` variants to `ProposalType`, `ExtensionType`, and `CredentialType` enums |
There was a problem hiding this comment.
These are actually changes to existing enums. So this should also get mentioned in the Changed section.
| 1. **Test extensibility**: Ensure implementations don't reject messages containing unknown values | ||
| 2. **Prevent ossification**: Help maintain forward compatibility by exercising unknown value handling paths | ||
| 3. **Identify bugs**: Catch implementations that incorrectly assume all possible values are known | ||
|
|
There was a problem hiding this comment.
I think we need to make clear here that there are
- the grease values defined in the RFC. And when not using a manually defined value, that's what's being used by OpenMLS. Also any check like
is_grease()is only defined for these values. - any other grease value. For these we can't distinguish whether they are supposed to be grease values or just unknown IDs.
But since the entire point of grease values is NOT to check for them. We need to make sure that it's clear that this is not how they should be used.
But instead that this allows applications to inject grease values to discourage other implementations from failing on unknown values and hard coding too many things.
There's some more text about this further down. Maybe linking there would be ok as well.
2 participants
This PR implements GREASE (Generate Random Extensions And Sustain Extensibility) support as defined in RFC 9420 Section 13.5. GREASE injects reserved values (
0x0A0A,0x1A1A, etc.) to ensure implementations handle unknown values correctly and maintain forward compatibility.Key Changes
Grease(u16)variants toProposalType,ExtensionType, andCredentialTypeenumsis_grease()methods for all GREASE-capable types includingVerifiableCiphersuiteTesting & Documentation
book/src/user_manual/grease.md