Flesh out the extensions story #296
Conversation
|
I think this could also be useful for deniability. |
|
|
||
| * Set the confirmed transcript hash in the new state to the value of the | ||
| `confirmed_transcript_hash` in the GroupInfo. | ||
|
|
||
| * Verify the confirmation MAC in the GroupInfo using the derived confirmation | ||
| key and the `confirmed_transcript_hash` from the GroupInfo. | ||
|
|
||
| # Extensibility |
There was a problem hiding this comment.
This means we need some more text in the IANA considerations about setting up the space.
There was a problem hiding this comment.
You've essentially just added extension fields without defining /how/ they'll interact with the protocol. Which tells me they're probably meant to be able to change /anything/ about the protocol. In that case, it needs to be clear that all extensions (outside of CIKs) are effectively mandatory, and that we can't have non-mandatory extensions.
draft-ietf-mls-protocol.md
Outdated
|
|
||
| This protocol includes a mechanism for negotiating extension parameters similar | ||
| to one in TLS {{RFC8446}}. In TLS, extension negotiation is one-to-one. The | ||
| client offers extensions in its ClientHello message, and the server expersses |
draft-ietf-mls-protocol.md
Outdated
| # Extensibility | ||
|
|
||
| This protocol includes a mechanism for negotiating extension parameters similar | ||
| to one in TLS {{RFC8446}}. In TLS, extension negotiation is one-to-one. The |
There was a problem hiding this comment.
"to the one"
"one-to-one: the"
draft-ietf-mls-protocol.md
Outdated
| places: | ||
|
|
||
| * In ClientInitKeys, to describe client capabilities and aspects of their | ||
| particiation in the group (once in the ratchet tree) |
draft-ietf-mls-protocol.md
Outdated
| * For each parent of the common ancestor, up to the root of the tree, derive | ||
| a new path secret and set the private key for the node to the private key | ||
| derived from the path secret. The private key MUST be the private key | ||
| that correspondns to the public key in the node. |
|
I imagine we also need to define an IANA registry of extensions, designated experts, a private space? |
|
Filed #312 for the IANA stuff |
|
|
||
| [[ OPEN ISSUE: Should we put bounds on what an extension can change? For | ||
| example, should we make an explicit guarantee that as long as you're speaking | ||
| MLS 1.0, the format of the ClientInitKey will remain the same? (Analogous to |
There was a problem hiding this comment.
I think this would be good. Making sure the CIK format doesn't change is all I think you need for backwards-compatibility.
Co-Authored-By: Brendan McMillion <brendan@cloudflare.com>
Extensions in the CIK were only half of the story. To do things like RTreeKEM or fork/merge as extensions, we need the ability to (1) tell new members that the group is doing something different, and (2) confirm that all group members have the same view of the rules of the road. This PR adds extensions to the GroupInfo object for the first case, and to the Welcome object for the second, and a bunch of explanatory text to make it all work.
One thing this PR does not do is define a way to change extensions in a running group. You could in principle do this by sending new extensions in Commit that could overwrite or add to extensions. But that entails some messy questions (how do you delete an extension in use?), so it is currently left to an extension (heh), or to a group restart.
Depends on #295 to avoid conflicts in GroupInfo changes.