Safe extensions

[kkohbrok]

This PR is joint work with @mulmarta, @raphaelrobert and @psyoptix. It includes a brief section on general guidance, as well as the “safe extension API”.

(The following text was also sent to the MLS WG mailing list.)

The extension developer guidance section gives a brief overview over the different places in which MLS is extensible (GroupInfo, GroupContext, etc.) and what properties MLS can provide for extensions in each of those places. There is nothing that can’t be gleaned from the MLS specification or the architecture doc, but it might be a helpful summary for extension designers.

The main contribution of the PR is the safe extension API. The MLS specification doesn’t place any restrictions on what extensions can and can’t do, which means that in particular extensions can invalidate any and all of the security guarantees MLS and other extensions provide. While in some cases it makes sense for an extension to interfere with the main protocol mechanics, for the majority of extensions controlled access to a subset of the functionalities provided by MLS should be sufficient. The safe extensions API describes an interface that extensions can use to make use of functionalities like exporters, PSK injection, public key encryption, signatures, etc. without invalidating the privacy, authenticity and agreement properties of MLS. Similarly, extensions that only use this API do not interfere with any other extensions which only use this API. We call extensions that only use this API “safe extensions”.

For the most part, this is achieved through proper domain separation both between extensions and the MLS protocol, as well as between extensions.

As part of the API, the PR defines generic proposals, wire formats and credentials that can be safely used by extension developers. These definitions also mean that an extension developer won’t have to request IANA code points for any additional structs besides the extension itself.

The PR also provides two examples of safe extensions: The first example is a simple RBAC extension that keeps state externally. Note that there are many ways to implement RBAC and this is just an example (which will be modified in a later PR, see below). The second example is the already existing Targeted Messages extension, which we have adapted to use the safe extension API.

Finally, we want to note that this PR is only step one. In the next step, we want to provide a safe way of reading and writing to (the state of) GroupContext extensions beyond a group context extension proposal. We felt that the PR had already gotten quite big and we wanted to put it up for discussion in time for a fresh draft of the extension doc before IETF 118.

[TWal]

It's a good idea -- it would be a shame if an extension reduced the security of MLS!

I only skimmed through it, but I do have a few remarks.

To ensure disambiguation between signatures / HPKE encryptions / exported secrets, we created a IANA registry for their labels, to ensure an extension doesn't reuse a label defined in MLS, or defined in another extension. The safe extension API do use these labels (and update the IANA registry) to define new "safe" versions of these functions, but then I think we then need another IANA registry to ensure two extensions don't use the same label e.g. for SafeSignWithLabel (same for other "safe" functions).

And a small nit, VerifyWithLabel / SignWithLabel are always used with a label consisting of the signature input type name (here, LabeledExtensionContent), although here it's used with the labels ExtensionsDataTBS and ExtensionDataTBS (which is a bug by the way!)

[psyoptix]

yup, domain separation between extensions is critical to achieve the Safe API's goals. the API does this using just the (IANA registered) Extension Type. A safe extension must register its own Extension Type unique among all other safe extensions with IANA. That already gives us a unique number we can extend to domain separate all labels.

For example, for a safe extension to use HPKE the safe API enforces that the HPKE label is LabeledExtensionContent which contains the ExtensionContent which in turn has an ExtensionType field. As that value is different for each safe extension the full HPKE labels for different extensions is always distinct.

The same idea is used for all other extension defined labels in the safe API which means the only value a new extension must register with IANA is its Extension Type.

[kkohbrok]

And a small nit, VerifyWithLabel / SignWithLabel are always used with a label consisting of the signature input type name (here, LabeledExtensionContent), although here it's used with the labels ExtensionsDataTBS and ExtensionDataTBS (which is a bug by the way!)

Thanks for pointing this out! I've changed the labels accordingly.

[TWal]

Ah indeed, I didn't notice the extension type was included. My remark doesn't apply then, there is correct domain separation between extensions!

[rohan-wire]

My overall reaction is that this is much more straightforward than I imagined when Joël described the idea. I'll just emphasize again to please make our PRs small and atomic. Updating Targeted messages to use Safe Extensions, and RBAC should be in separate PRs.

The IANA Considerations and Security Considerations section need to be one top-level section with level-2 headings. You should also add a paragraph under the top-level Contributors section

[kkohbrok]

Thinking some more about it, I think updating the targeted messages extension in this PR should be fine since it's just an update, not a change in its semantics. I have removed the RBAC extension, though. We won't create a PR for it right now, but we might re-use it as an example for our next pass over the safe extensions API.

I also updated the section on proposals, to allow "safe" definition of proposals for external commits. Generally, there is still some work to be done on what it means for a proposal to be safe, but that, too, we'll save for the next iteration.