idnits 2.17.1 draft-ietf-mls-protocol-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (31 October 2020) is 1272 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'C' is mentioned on line 762, but not defined == Missing Reference: 'CD' is mentioned on line 762, but not defined == Missing Reference: 'A' is mentioned on line 762, but not defined -- Looks like a reference, but probably isn't: '0' on line 1055 -- Looks like a reference, but probably isn't: '1' on line 944 == Missing Reference: 'X' is mentioned on line 951, but not defined -- Looks like a reference, but probably isn't: '4' on line 2042 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-06 == Outdated reference: A later version (-13) exists of draft-ietf-mls-architecture-05 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-34 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft Cisco 4 Intended status: Informational B. Beurdouche 5 Expires: 4 May 2021 Inria 6 J. Millican 7 Facebook 8 E. Omara 9 Google 10 K. Cohn-Gordon 11 University of Oxford 12 R. Robert 13 Wire 14 31 October 2020 16 The Messaging Layer Security (MLS) Protocol 17 draft-ietf-mls-protocol-10 19 Abstract 21 Messaging applications are increasingly making use of end-to-end 22 security mechanisms to ensure that messages are only accessible to 23 the communicating endpoints, and not to any servers involved in 24 delivering messages. Establishing keys to provide such protections 25 is challenging for group chat settings, in which more than two 26 clients need to agree on a key but may not be online at the same 27 time. In this document, we specify a key establishment protocol that 28 provides efficient asynchronous group key establishment with forward 29 secrecy and post-compromise security for groups in size ranging from 30 two to thousands. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 4 May 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 70 5. Ratchet Trees . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. Tree Computation Terminology . . . . . . . . . . . . . . 14 72 5.2. Ratchet Tree Nodes . . . . . . . . . . . . . . . . . . . 16 73 5.3. Views of a Ratchet Tree . . . . . . . . . . . . . . . . . 17 74 5.4. Ratchet Tree Evolution . . . . . . . . . . . . . . . . . 18 75 5.5. Synchronizing Views of the Tree . . . . . . . . . . . . . 20 76 6. Cryptographic Objects . . . . . . . . . . . . . . . . . . . . 21 77 6.1. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . 21 78 6.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 22 79 7. Key Packages . . . . . . . . . . . . . . . . . . . . . . . . 24 80 7.1. Client Capabilities . . . . . . . . . . . . . . . . . . . 25 81 7.2. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 26 82 7.3. KeyPackage Identifiers . . . . . . . . . . . . . . . . . 26 83 7.4. Parent Hash . . . . . . . . . . . . . . . . . . . . . . . 26 84 7.5. Tree Hashes . . . . . . . . . . . . . . . . . . . . . . . 27 85 7.6. Group State . . . . . . . . . . . . . . . . . . . . . . . 28 86 7.7. Update Paths . . . . . . . . . . . . . . . . . . . . . . 29 87 8. Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . 30 88 8.1. External Initialization . . . . . . . . . . . . . . . . . 33 89 8.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 34 90 8.3. Secret Tree . . . . . . . . . . . . . . . . . . . . . . . 36 91 8.4. Encryption Keys . . . . . . . . . . . . . . . . . . . . . 37 92 8.5. Deletion Schedule . . . . . . . . . . . . . . . . . . . . 38 93 8.6. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 39 94 8.7. Resumption Secret . . . . . . . . . . . . . . . . . . . . 40 95 8.8. State Authentication Keys . . . . . . . . . . . . . . . . 40 96 9. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 40 97 9.1. Content Authentication . . . . . . . . . . . . . . . . . 43 98 9.2. Content Encryption . . . . . . . . . . . . . . . . . . . 44 99 9.3. Sender Data Encryption . . . . . . . . . . . . . . . . . 45 100 10. Group Creation . . . . . . . . . . . . . . . . . . . . . . . 46 101 10.1. Linking a New Group to an Existing Group . . . . . . . . 47 102 10.1.1. Sub-group Branching . . . . . . . . . . . . . . . . 48 103 11. Group Evolution . . . . . . . . . . . . . . . . . . . . . . . 48 104 11.1. Proposals . . . . . . . . . . . . . . . . . . . . . . . 48 105 11.1.1. Add . . . . . . . . . . . . . . . . . . . . . . . . 49 106 11.1.2. Update . . . . . . . . . . . . . . . . . . . . . . . 50 107 11.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . . 50 108 11.1.4. PreSharedKey . . . . . . . . . . . . . . . . . . . . 51 109 11.1.5. ReInit . . . . . . . . . . . . . . . . . . . . . . . 51 110 11.1.6. ExternalInit . . . . . . . . . . . . . . . . . . . . 52 111 11.1.7. External Proposals . . . . . . . . . . . . . . . . . 52 112 11.2. Commit . . . . . . . . . . . . . . . . . . . . . . . . . 53 113 11.2.1. External Commits . . . . . . . . . . . . . . . . . . 59 114 11.2.2. Welcoming New Members . . . . . . . . . . . . . . . 60 115 11.3. Ratchet Tree Extension . . . . . . . . . . . . . . . . . 63 116 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 64 117 13. Sequencing of State Changes . . . . . . . . . . . . . . . . . 66 118 13.1. Server-Enforced Ordering . . . . . . . . . . . . . . . . 67 119 13.2. Client-Enforced Ordering . . . . . . . . . . . . . . . . 67 120 14. Application Messages . . . . . . . . . . . . . . . . . . . . 67 121 14.1. Message Encryption and Decryption . . . . . . . . . . . 68 122 14.2. Restrictions . . . . . . . . . . . . . . . . . . . . . . 69 123 14.3. Delayed and Reordered Application messages . . . . . . . 69 124 15. Security Considerations . . . . . . . . . . . . . . . . . . . 69 125 15.1. Confidentiality of the Group Secrets . . . . . . . . . . 69 126 15.2. Authentication . . . . . . . . . . . . . . . . . . . . . 70 127 15.3. Forward Secrecy and Post-Compromise Security . . . . . . 70 128 15.4. InitKey Reuse . . . . . . . . . . . . . . . . . . . . . 70 129 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 130 16.1. MLS Ciphersuites . . . . . . . . . . . . . . . . . . . . 71 131 16.2. MLS Extension Types . . . . . . . . . . . . . . . . . . 74 132 16.3. MLS Credential Types . . . . . . . . . . . . . . . . . . 75 133 16.4. MLS Designated Expert Pool . . . . . . . . . . . . . . . 76 134 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 135 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 136 18.1. Normative References . . . . . . . . . . . . . . . . . . 78 137 18.2. Informative References . . . . . . . . . . . . . . . . . 79 138 Appendix A. Tree Math . . . . . . . . . . . . . . . . . . . . . 81 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 141 1. Introduction 143 DISCLAIMER: This is a work-in-progress draft of MLS and has not yet 144 seen significant security analysis. It should not be used as a basis 145 for building production systems. 147 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 148 draft is maintained in GitHub. Suggested changes should be submitted 149 as pull requests at https://github.com/mlswg/mls-protocol. 150 Instructions are on that page as well. Editorial changes can be 151 managed in GitHub, but any substantive change should be discussed on 152 the MLS mailing list. 154 A group of users who want to send each other encrypted messages needs 155 a way to derive shared symmetric encryption keys. For two parties, 156 this problem has been studied thoroughly, with the Double Ratchet 157 emerging as a common solution [doubleratchet] [signal]. Channels 158 implementing the Double Ratchet enjoy fine-grained forward secrecy as 159 well as post-compromise security, but are nonetheless efficient 160 enough for heavy use over low-bandwidth networks. 162 For a group of size greater than two, a common strategy is to 163 unilaterally broadcast symmetric "sender" keys over existing shared 164 symmetric channels, and then for each member to send messages to the 165 group encrypted with their own sender key. Unfortunately, while this 166 improves efficiency over pairwise broadcast of individual messages 167 and provides forward secrecy (with the addition of a hash ratchet), 168 it is difficult to achieve post-compromise security with sender keys. 169 An adversary who learns a sender key can often indefinitely and 170 passively eavesdrop on that member's messages. Generating and 171 distributing a new sender key provides a form of post-compromise 172 security with regard to that sender. However, it requires 173 computation and communications resources that scale linearly with the 174 size of the group. 176 In this document, we describe a protocol based on tree structures 177 that enable asynchronous group keying with forward secrecy and post- 178 compromise security. Based on earlier work on "asynchronous 179 ratcheting trees" [art], the protocol presented here uses an 180 asynchronous key-encapsulation mechanism for tree structures. This 181 mechanism allows the members of the group to derive and update shared 182 keys with costs that scale as the log of the group size. 184 1.1. Change Log 186 RFC EDITOR PLEASE DELETE THIS SECTION. 188 draft-10 189 * Allow new members to join via an external Commit (*) 191 * Enable proposals to be sent inline in a Commit (*) 193 * Re-enable constant-time Add (*) 195 * Change expiration extension to lifetime extension (*) 197 * Make the tree in the Welcome optional (*) 199 * PSK injection, re-init, sub-group branching (*) 201 * Require the initial init_secret to be a random value (*) 203 * Remove explicit sender data nonce (*) 205 * Do not encrypt to joiners in UpdatePath generation (*) 207 * Move MLSPlaintext signature under the confirmation tag (*) 209 * Explicitly authenticate group membership with MLSPLaintext (*) 211 * Clarify X509Credential structure (*) 213 * Remove uneeded interim transcript hash from GroupInfo (*) 215 * IANA considerations 217 * Derive an authentication secret 219 * Use Extract/Expand from HPKE KDF 221 * Clarify that application messages MUST be encrypted 223 draft-09 225 * Remove blanking of nodes on Add (*) 227 * Change epoch numbers to uint64 (*) 229 * Add PSK inputs (*) 231 * Add key schedule exporter (*) 233 * Sign the updated direct path on Commit, using "parent hashes" and 234 one signature per leaf (*) 236 * Use structured types for external senders (*) 237 * Redesign Welcome to include confirmation and use derived keys (*) 239 * Remove ignored proposals (*) 241 * Always include an Update with a Commit (*) 243 * Add per-message entropy to guard against nonce reuse (*) 245 * Use the same hash ratchet construct for both application and 246 handshake keys (*) 248 * Add more ciphersuites 250 * Use HKDF to derive key pairs (*) 252 * Mandate expiration of ClientInitKeys (*) 254 * Add extensions to GroupContext and flesh out the extensibility 255 story (*) 257 * Rename ClientInitKey to KeyPackage 259 draft-08 261 * Change ClientInitKeys so that they only refer to one ciphersuite 262 (*) 264 * Decompose group operations into Proposals and Commits (*) 266 * Enable Add and Remove proposals from outside the group (*) 268 * Replace Init messages with multi-recipient Welcome message (*) 270 * Add extensions to ClientInitKeys for expiration and downgrade 271 resistance (*) 273 * Allow multiple Proposals and a single Commit in one MLSPlaintext 274 (*) 276 draft-07 278 * Initial version of the Tree based Application Key Schedule (*) 280 * Initial definition of the Init message for group creation (*) 282 * Fix issue with the transcript used for newcomers (*) 284 * Clarifications on message framing and HPKE contexts (*) 285 * Reorder blanking and update in the Remove operation (*) 287 * Rename the GroupState structure to GroupContext (*) 289 * Rename UserInitKey to ClientInitKey 291 * Resolve the circular dependency that draft-05 introduced in the 292 confirmation MAC calculation (*) 294 * Cover the entire MLSPlaintext in the transcript hash (*) 296 draft-05 298 * Common framing for handshake and application messages (*) 300 * Handshake message encryption (*) 302 * Convert from literal state to a commitment via the "tree hash" (*) 304 * Add credentials to the tree and remove the "roster" concept (*) 306 * Remove the secret field from tree node values 308 draft-04 310 * Updating the language to be similar to the Architecture document 312 * ECIES is now renamed in favor of HPKE (*) 314 * Using a KDF instead of a Hash in TreeKEM (*) 316 draft-03 318 * Added ciphersuites and signature schemes (*) 320 * Re-ordered fields in UserInitKey to make parsing easier (*) 322 * Fixed inconsistencies between Welcome and GroupState (*) 324 * Added encryption of the Welcome message (*) 326 draft-02 328 * Removed ART (*) 330 * Allowed partial trees to avoid double-joins (*) 331 * Added explicit key confirmation (*) 333 draft-01 335 * Initial description of the Message Protection mechanism. (*) 337 * Initial specification proposal for the Application Key Schedule 338 using the per-participant chaining of the Application Secret 339 design. (*) 341 * Initial specification proposal for an encryption mechanism to 342 protect Application Messages using an AEAD scheme. (*) 344 * Initial specification proposal for an authentication mechanism of 345 Application Messages using signatures. (*) 347 * Initial specification proposal for a padding mechanism to 348 improving protection of Application Messages against traffic 349 analysis. (*) 351 * Inversion of the Group Init Add and Application Secret derivations 352 in the Handshake Key Schedule to be ease chaining in case we 353 switch design. (*) 355 * Removal of the UserAdd construct and split of GroupAdd into Add 356 and Welcome messages (*) 358 * Initial proposal for authenticating handshake messages by signing 359 over group state and including group state in the key schedule (*) 361 * Added an appendix with example code for tree math 363 * Changed the ECIES mechanism used by TreeKEM so that it uses nonces 364 generated from the shared secret 366 draft-00 368 * Initial adoption of draft-barnes-mls-protocol-01 as a WG item. 370 2. Terminology 372 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 373 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 374 "OPTIONAL" in this document are to be interpreted as described in BCP 375 14 [RFC2119] [RFC8174] when, and only when, they appear in all 376 capitals, as shown here. 378 Client: An agent that uses this protocol to establish shared 379 cryptographic state with other clients. A client is defined by 380 the cryptographic keys it holds. 382 Group: A collection of clients with shared cryptographic state. 384 Member: A client that is included in the shared state of a group, 385 hence has access to the group's secrets. 387 Key Package: A signed object describing a client's identity and 388 capabilities, and including a hybrid public-key encryption (HPKE 389 [I-D.irtf-cfrg-hpke] ) public key that can be used to encrypt to 390 that client. 392 Initialization Key (InitKey): A key package that is prepublished by 393 a client, which other clients can use to introduce the client to a 394 new group. 396 Signature Key: A signing key pair used to authenticate the sender of 397 a message. 399 Terminology specific to tree computations is described in Section 5. 401 We use the TLS presentation language [RFC8446] to describe the 402 structure of protocol messages. 404 3. Basic Assumptions 406 This protocol is designed to execute in the context of a Service 407 Provider (SP) as described in [I-D.ietf-mls-architecture]. In 408 particular, we assume the SP provides the following services: 410 * A signature key provider which allows clients to authenticate 411 protocol messages in a group. 413 * A broadcast channel, for each group, which will relay a message to 414 all members of a group. For the most part, we assume that this 415 channel delivers messages in the same order to all participants. 416 (See Section 13 for further considerations.) 418 * A directory to which clients can publish key packages and download 419 key packages for other participants. 421 4. Protocol Overview 423 The goal of this protocol is to allow a group of clients to exchange 424 confidential and authenticated messages. It does so by deriving a 425 sequence of secrets and keys known only to members. Those should be 426 secret against an active network adversary and should have both 427 forward secrecy and post-compromise security with respect to 428 compromise of any members. 430 We describe the information stored by each client as _state_, which 431 includes both public and private data. An initial state is set up by 432 a group creator, which is a group containing only itself. The 433 creator then sends _Add_ proposals for each client in the initial set 434 of members, followed by a _Commit_ message which incorporates all of 435 the _Adds_ into the group state. Finally, the group creator 436 generates a _Welcome_ message corresponding to the Commit and sends 437 this directly to all the new members, who can use the information it 438 contains to set up their own group state and derive a shared secret. 439 Members exchange Commit messages for post-compromise security, to add 440 new members, and to remove existing members. These messages produce 441 new shared secrets which are causally linked to their predecessors, 442 forming a logical Directed Acyclic Graph (DAG) of states. 444 The protocol algorithms we specify here follow. Each algorithm 445 specifies both (i) how a client performs the operation and (ii) how 446 other clients update their state based on it. 448 There are three major operations in the lifecycle of a group: 450 * Adding a member, initiated by a current member; 452 * Updating the leaf secret of a member; 454 * Removing a member. 456 Each of these operations is "proposed" by sending a message of the 457 corresponding type (Add / Update / Remove). The state of the group 458 is not changed, however, until a Commit message is sent to provide 459 the group with fresh entropy. In this section, we show each proposal 460 being committed immediately, but in more advanced deployment cases an 461 application might gather several proposals before committing them all 462 at once. 464 Before the initialization of a group, clients publish InitKeys (as 465 KeyPackage objects) to a directory provided by the Service Provider. 467 Group 468 A B C Directory Channel 469 | | | | | 470 | KeyPackageA | | | | 471 |------------------------------------------------->| | 472 | | | | | 473 | | KeyPackageB | | | 474 | |-------------------------------->| | 475 | | | | | 476 | | | KeyPackageC | | 477 | | |--------------->| | 478 | | | | | 480 When a client A wants to establish a group with B and C, it first 481 initializes a group state containing only itself and downloads 482 KeyPackages for B and C. For each member, A generates an Add and 483 Commit message adding that member, and broadcasts them to the group. 484 It also generates a Welcome message and sends this directly to the 485 new member (there's no need to send it to the group). Only after A 486 has received its Commit message back from the server does it update 487 its state to reflect the new member's addition. 489 Upon receiving the Welcome message and the corresponding Commit, the 490 new member will be able to read and send new messages to the group. 491 Messages received before the client has joined the group are ignored. 493 Group 494 A B C Directory Channel 495 | | | | | 496 | KeyPackageB, KeyPackageC | | 497 |<-------------------------------------------| | 498 |state.init() | | | | 499 | | | | | 500 | | | | Add(A->AB) | 501 | | | | Commit(Add) | 502 |--------------------------------------------------------------->| 503 | | | | | 504 | Welcome(B) | | | | 505 |------------->|state.init() | | | 506 | | | | | 507 | | | | Add(A->AB) | 508 | | | | Commit(Add) | 509 |<---------------------------------------------------------------| 510 |state.add(B) |<------------------------------------------------| 511 | |state.join() | | | 512 | | | | | 513 | | | | Add(AB->ABC) | 514 | | | | Commit(Add) | 515 |--------------------------------------------------------------->| 516 | | | | | 517 | | Welcome(C) | | | 518 |---------------------------->|state.init() | | 519 | | | | | 520 | | | | Add(AB->ABC) | 521 | | | | Commit(Add) | 522 |<---------------------------------------------------------------| 523 |state.add(C) |<------------------------------------------------| 524 | |state.add(C) |<---------------------------------| 525 | | |state.join() | | 527 Subsequent additions of group members proceed in the same way. Any 528 member of the group can download a KeyPackage for a new client and 529 broadcast an Add message that the current group can use to update 530 their state, and a Welcome message that the new client can use to 531 initialize its state. 533 To enforce the forward secrecy and post-compromise security of 534 messages, each member periodically updates their leaf secret. Any 535 member can update this information at any time by generating a fresh 536 KeyPackage and sending an Update message followed by a Commit 537 message. Once all members have processed both, the group's secrets 538 will be unknown to an attacker that had compromised the sender's 539 prior leaf secret. 541 Update messages should be sent at regular intervals of time as long 542 as the group is active, and members that don't update should 543 eventually be removed from the group. It's left to the application 544 to determine an appropriate amount of time between Updates. 546 Group 547 A B ... Z Directory Channel 548 | | | | | 549 | | Update(B) | | | 550 | |------------------------------------------->| 551 | Commit(Upd) | | | | 552 |---------------------------------------------------------->| 553 | | | | | 554 | | | | Update(B) | 555 | | | | Commit(Upd) | 556 |<----------------------------------------------------------| 557 |state.upd(B) |<-------------------------------------------| 558 | |state.upd(B) |<----------------------------| 559 | | |state.upd(B) | | 560 | | | | | 562 Members are removed from the group in a similar way. Any member of 563 the group can send a Remove proposal followed by a Commit message, 564 which adds new entropy to the group state that's known to all except 565 the removed member. Note that this does not necessarily imply that 566 any member is actually allowed to evict other members; groups can 567 enforce access control policies on top of these basic mechanism. 569 Group 570 A B ... Z Directory Channel 571 | | | | | 572 | | | Remove(B) | | 573 | | | Commit(Rem) | | 574 | | |---------------------------->| 575 | | | | | 576 | | | | Remove(B) | 577 | | | | Commit(Rem) | 578 |<----------------------------------------------------------| 579 |state.rem(B) | |<----------------------------| 580 | | |state.rem(B) | | 581 | | | | | 582 | | | | | 584 5. Ratchet Trees 586 The protocol uses "ratchet trees" for deriving shared secrets among a 587 group of clients. 589 5.1. Tree Computation Terminology 591 Trees consist of _nodes_. A node is a _leaf_ if it has no children, 592 and a _parent_ otherwise; note that all parents in our trees have 593 precisely two children, a _left_ child and a _right_ child. A node 594 is the _root_ of a tree if it has no parents, and _intermediate_ if 595 it has both children and parents. The _descendants_ of a node are 596 that node, its children, and the descendants of its children, and we 597 say a tree _contains_ a node if that node is a descendant of the root 598 of the tree. Nodes are _siblings_ if they share the same parent. 600 A _subtree_ of a tree is the tree given by the descendants of any 601 node, the _head_ of the subtree. The _size_ of a tree or subtree is 602 the number of leaf nodes it contains. For a given parent node, its 603 _left subtree_ is the subtree with its left child as head 604 (respectively _right subtree_). 606 All trees used in this protocol are left-balanced binary trees. A 607 binary tree is _full_ (and _balanced_) if its size is a power of two 608 and for any parent node in the tree, its left and right subtrees have 609 the same size. 611 A binary tree is _left-balanced_ if for every parent, either the 612 parent is balanced, or the left subtree of that parent is the largest 613 full subtree that could be constructed from the leaves present in the 614 parent's own subtree. Given a list of "n" items, there is a unique 615 left-balanced binary tree structure with these elements as leaves. 617 (Note that left-balanced binary trees are the same structure that is 618 used for the Merkle trees in the Certificate Transparency protocol 619 [I-D.ietf-trans-rfc6962-bis].) 621 The _direct path_ of a root is the empty list, and of any other node 622 is the concatenation of that node's parent along with the parent's 623 direct path. The _copath_ of a node is the node's sibling 624 concatenated with the list of siblings of all the nodes in its direct 625 path, excluding the root. 627 For example, in the below tree: 629 * The direct path of C is (CD, ABCD, ABCDEFG) 631 * The copath of C is (D, AB, EFG) 632 ABCDEFG 633 / \ 634 / \ 635 / \ 636 ABCD EFG 637 / \ / \ 638 / \ / \ 639 AB CD EF | 640 / \ / \ / \ | 641 A B C D E F G 643 1 1 1 644 0 1 2 3 4 5 6 7 8 9 0 1 2 646 Each node in the tree is assigned a _node index_, starting at zero 647 and running from left to right. A node is a leaf node if and only if 648 it has an even index. The node indices for the nodes in the above 649 tree are as follows: 651 * 0 = A 653 * 1 = AB 655 * 2 = B 657 * 3 = ABCD 659 * 4 = C 661 * 5 = CD 663 * 6 = D 665 * 7 = ABCDEFG 667 * 8 = E 669 * 9 = EF 671 * 10 = F 673 * 11 = EFG 675 * 12 = G 677 The leaves of the tree are indexed separately, using a _leaf index_, 678 since the protocol messages only need to refer to leaves in the tree. 679 Like nodes, leaves are numbered left to right. The node with leaf 680 index "k" is also called the "k-th" leaf. Note that given the above 681 numbering, a node is a leaf node if and only if it has an even node 682 index, and a leaf node's leaf index is half its node index. The leaf 683 indices in the above tree are as follows: 685 * 0 = A 687 * 1 = B 689 * 2 = C 691 * 3 = D 693 * 4 = E 695 * 5 = F 697 * 6 = G 699 5.2. Ratchet Tree Nodes 701 A particular instance of a ratchet tree is defined by the same 702 parameters that define an instance of HPKE, namely: 704 * A Key Encapsulation Mechanism (KEM), including a "DeriveKeyPair" 705 function that creates a key pair for the KEM from a symmetric 706 secret 708 * A Key Derivation Function (KDF), including "Extract" and "Expand" 709 functions 711 * An AEAD encryption scheme 713 Each node in a ratchet tree contains up to five values: 715 * A private key (only within the member's direct path, see below) 717 * A public key 719 * An ordered list of leaf indices for "unmerged" leaves (see 720 Section 5.3) 722 * A credential (only for leaf nodes) 724 * A hash of the node's parent, as of the last time the node was 725 changed. 727 The conditions under which each of these values must or must not be 728 present are laid out in Section 5.3. 730 A node in the tree may also be _blank_, indicating that no value is 731 present at that node. The _resolution_ of a node is an ordered list 732 of non-blank nodes that collectively cover all non-blank descendants 733 of the node. 735 * The resolution of a non-blank node comprises the node itself, 736 followed by its list of unmerged leaves, if any 738 * The resolution of a blank leaf node is the empty list 740 * The resolution of a blank intermediate node is the result of 741 concatenating the resolution of its left child with the resolution 742 of its right child, in that order 744 For example, consider the following tree, where the "_" character 745 represents a blank node: 747 _ 748 / \ 749 / \ 750 _ CD[C] 751 / \ / \ 752 A _ C D 754 0 1 2 3 4 5 6 756 In this tree, we can see all of the above rules in play: 758 * The resolution of node 5 is the list [CD, C] 760 * The resolution of node 2 is the empty list [] 762 * The resolution of node 3 is the list [A, CD, C] 764 Every node, regardless of whether the node is blank or populated, has 765 a corresponding _hash_ that summarizes the contents of the subtree 766 below that node. The rules for computing these hashes are described 767 in Section 7.5. 769 5.3. Views of a Ratchet Tree 771 We generally assume that each participant maintains a complete and 772 up-to-date view of the public state of the group's ratchet tree, 773 including the public keys for all nodes and the credentials 774 associated with the leaf nodes. 776 No participant in an MLS group knows the private key associated with 777 every node in the tree. Instead, each member is assigned to a leaf 778 of the tree, which determines the subset of private keys it knows. 779 The credential stored at that leaf is one provided by the member. 781 In particular, MLS maintains the members' views of the tree in such a 782 way as to maintain the _tree invariant_: 784 The private key for a node in the tree is known to a member of 785 the group only if that member's leaf is a descendant of 786 the node. 788 In other words, if a node is not blank, then it holds a public key. 789 The corresponding private key is known only to members occupying 790 leaves below that node. 792 The reverse implication is not true: A member may not know the 793 private keys of all the intermediate nodes they're below. Such a 794 member has an _unmerged_ leaf. Encrypting to an intermediate node 795 requires encrypting to the node's public key, as well as the public 796 keys of all the unmerged leaves below it. A leaf is unmerged when it 797 is first added, because the process of adding the leaf does not give 798 it access to all of the nodes above it in the tree. Leaves are 799 "merged" as they receive the private keys for nodes, as described in 800 Section 5.4. 802 5.4. Ratchet Tree Evolution 804 A member of an MLS group advances the key schedule to provide forward 805 secrecy and post-compromise security by providing the group with 806 fresh key material to be added into the group's shared secret. To do 807 so, one member of the group generates fresh key material, applies it 808 to their local tree state, and then sends this key material to other 809 members in the group via an UpdatePath message (see Section 7.7) . 810 All other group members then apply the key material in the UpdatePath 811 to their own local tree state to derive the group's now-updated 812 shared secret. 814 To begin, the generator of the UpdatePath updates its leaf KeyPackage 815 and its direct path to the root with new secret values. The HPKE 816 leaf public key within the KeyPackage MUST be derived from a freshly 817 generated HPKE secret key to provide post-compromise security. 819 The generator of the UpdatePath starts by sampling a fresh random 820 value called "leaf_secret", and uses the leaf_secret to generate 821 their leaf HPKE key pair (see Section 7) and to seed a sequence of 822 "path secrets", one for each ancestor of its leaf. In this setting, 823 path_secret[0] refers to the node directly above the leaf, 824 path_secret[1] for its parent, and so on. At each step, the path 825 secret is used to derive a new secret value for the corresponding 826 node, from which the node's key pair is derived. 828 leaf_node_secret = DeriveSecret(leaf_secret, "node") 829 path_secret[0] = DeriveSecret(leaf_secret, "path") 831 path_secret[n] = DeriveSecret(path_secret[n-1], "path") 832 node_secret[n] = DeriveSecret(path_secret[n], "node") 834 leaf_priv, leaf_pub = KEM.DeriveKeyPair(leaf_node_secret) 835 node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n]) 837 For example, suppose there is a group with four members: 839 G 840 / \ 841 / \ 842 / \ 843 E _ 844 / \ / \ 845 A B C D 847 If member B subsequently generates an UpdatePath based on a secret 848 "leaf_secret", then it would generate the following sequence of path 849 secrets: 851 path_secret[1] --> node_secret[1] --> node_priv[1], node_pub[1] 852 ^ 853 | 854 path_secret[0] --> node_secret[0] --> node_priv[0], node_pub[0] 855 ^ 856 | 857 leaf_secret --> leaf_node_secret --> leaf_priv, leaf_pub 858 ~> leaf_key_package 860 After applying the UpdatePath, the tree will have the following 861 structure, where "np[i]" represents the node_priv values generated as 862 described above: 864 np[1] 865 / \ 866 np[0] _ 867 / \ / \ 868 A B C D 870 After performing these operations, the generator of the UpdatePath 871 MUST delete the leaf_secret. 873 5.5. Synchronizing Views of the Tree 875 After generating fresh key material and applying it to ratchet 876 forward their local tree state as described in the prior section, the 877 generator must broadcast this update to other members of the group in 878 a Commit message, who apply it to keep their local views of the tree 879 in sync with the sender's. More specifically, when a member commits 880 a change to the tree (e.g., to add or remove a member), it transmits 881 an UpdatePath message containing a set of public and encrypted 882 private values for intermediate nodes in the direct path of a leaf. 883 The other members of the group use these values to update their view 884 of the tree, aligning their copy of the tree to the sender's. 886 To transmit this update, the sender broadcasts to the group the 887 following information for each node in the direct path of the leaf, 888 including the root: 890 * The public key for the node 892 * Zero or more encrypted copies of the path secret corresponding to 893 the node 895 The path secret value for a given node is encrypted for the subtree 896 corresponding to the parent's non-updated child, that is, the child 897 on the copath of the leaf node. There is one encrypted path secret 898 for each public key in the resolution of the non-updated child. 900 The recipient of a path update processes it with the following steps: 902 1. Compute the updated path secrets. 904 * Identify a node in the direct path for which the local member 905 is in the subtree of the non-updated child. 907 * Identify a node in the resolution of the copath node for which 908 this node has a private key. 910 * Decrypt the path secret for the parent of the copath node 911 using the private key from the resolution node. 913 * Derive path secrets for ancestors of that node using the 914 algorithm described above. 916 * The recipient SHOULD verify that the received public keys 917 agree with the public keys derived from the new path_secret 918 values. 920 2. Merge the updated path secrets into the tree. 922 * For all updated nodes, 924 - Replace the public key for each node with the received 925 public key. 927 - Set the list of unmerged leaves to the empty list. 929 - Store the updated hash of the node's parent (represented as 930 a ParentNode struct), going from root to leaf, so that each 931 hash incorporates all the nodes above it. The root node 932 always has a zero-length hash for this value. 934 * For nodes where an updated path secret was computed in step 1, 935 compute the corresponding node key pair and replace the values 936 stored at the node with the computed values. 938 For example, in order to communicate the example update described in 939 the previous section, the sender would transmit the following values: 941 +============+==================================+ 942 | Public Key | Ciphertext(s) | 943 +============+==================================+ 944 | pk(ns[1]) | E(pk(C), ps[1]), E(pk(D), ps[1]) | 945 +------------+----------------------------------+ 946 | pk(ns[0]) | E(pk(A), ps[0]) | 947 +------------+----------------------------------+ 949 Table 1 951 In this table, the value pk(ns[X]) represents the public key derived 952 from the node secret X, whereas pk(X) represents the public leaf key 953 for user X. The value E(K, S) represents the public-key encryption 954 of the path secret S to the public key K. 956 After processing the update, each recipient MUST delete outdated key 957 material, specifically: 959 * The path secrets used to derive each updated node key pair. 961 * Each outdated node key pair that was replaced by the update. 963 6. Cryptographic Objects 965 6.1. Ciphersuites 967 Each MLS session uses a single ciphersuite that specifies the 968 following primitives to be used in group key computations: 970 * HPKE parameters: 972 - A Key Encapsulation Mechanism (KEM) 974 - A Key Derivation Function (KDF) 976 - An AEAD encryption algorithm 978 * A hash algorithm 980 * A signature algorithm 982 The HPKE parameters are used to instantiate HPKE [I-D.irtf-cfrg-hpke] 983 for the purpose of public-key encryption. The "DeriveKeyPair" 984 function associated to the KEM for the ciphersuite maps octet strings 985 to HPKE key pairs. 987 Ciphersuites are represented with the CipherSuite type. HPKE public 988 keys are opaque values in a format defined by the underlying protocol 989 (see the Cryptographic Dependencies section of the HPKE specification 990 for more information). 992 opaque HPKEPublicKey<1..2^16-1>; 994 The signature algorithm specified in the ciphersuite is the mandatory 995 algorithm to be used for signatures in MLSPlaintext and the tree 996 signatures. It MUST be the same as the signature algorithm specified 997 in the credential field of the KeyPackage objects in the leaves of 998 the tree (including the InitKeys used to add new members). 1000 The ciphersuites are defined in section Section 16.1. 1002 6.2. Credentials 1004 A member of a group authenticates the identities of other 1005 participants by means of credentials issued by some authentication 1006 system, like a PKI. Each type of credential MUST express the 1007 following data in the context of the group it is used with: 1009 * The public key of a signature key pair matching the 1010 SignatureScheme specified by the CipherSuite of the group 1012 * The identity of the holder of the private key 1014 Credentials MAY also include information that allows a relying party 1015 to verify the identity / signing key binding. 1017 Additionally, Credentials SHOULD specify the signature scheme 1018 corresponding to each contained public key. 1020 // See RFC 8446 and the IANA TLS SignatureScheme registry 1021 uint16 SignatureScheme; 1023 // See IANA registry for registered values 1024 uint16 CredentialType; 1026 struct { 1027 opaque identity<0..2^16-1>; 1028 SignatureScheme signature_scheme; 1029 opaque signature_key<0..2^16-1>; 1030 } BasicCredential; 1032 struct { 1033 opaque cert_data<0..2^16-1>; 1034 } Certificate; 1036 struct { 1037 CredentialType credential_type; 1038 select (Credential.credential_type) { 1039 case basic: 1040 BasicCredential; 1042 case x509: 1043 Certificate chain<1..2^32-1>; 1044 }; 1045 } Credential; 1047 A BasicCredential is a raw, unauthenticated assertion of an identity/ 1048 key binding. The format of the key in the "public_key" field is 1049 defined by the relevant ciphersuite: the group ciphersuite for a 1050 credential in a ratchet tree, the KeyPackage ciphersuite for a 1051 credential in a KeyPackage object. 1053 For X509Credential, each entry in the chain represents a single DER- 1054 encoded X509 certificate. The chain is ordered such that the first 1055 entry (chain[0]) is the end-entity certificate and each subsequent 1056 certificate in the chain MUST be the issuer of the previous 1057 certificate. The algorithm for the "public_key" in the end-entity 1058 certificate MUST match the relevant ciphersuite. 1060 For ciphersuites using Ed25519 or Ed448 signature schemes, the public 1061 key is in the format specified [RFC8032]. For ciphersuites using 1062 ECDSA with the NIST curves P-256 or P-521, the public key is the 1063 output of the uncompressed Elliptic-Curve-Point-to-Octet-String 1064 conversion according to [SECG]. 1066 Note that each new credential that has not already been validated by 1067 the application MUST be validated against the Authentication Service. 1069 7. Key Packages 1071 In order to facilitate asynchronous addition of clients to a group, 1072 it is possible to pre-publish key packages that provide some public 1073 information about a user. KeyPackage structures provide information 1074 about a client that any existing member can use to add this client to 1075 the group asynchronously. 1077 A KeyPackage object specifies a ciphersuite that the client supports, 1078 as well as providing a public key that others can use for key 1079 agreement. The client's signature key can be updated throughout the 1080 lifetime of the group by sending a new KeyPackage with a new 1081 Credential. However, the identity MUST be the same in both 1082 Credentials and the new Credential MUST be validated by the 1083 authentication service. 1085 When used as InitKeys, KeyPackages are intended to be used only once 1086 and SHOULD NOT be reused except in case of last resort. (See 1087 Section 15.4). Clients MAY generate and publish multiple InitKeys to 1088 support multiple ciphersuites. 1090 KeyPackages contain a public key chosen by the client, which the 1091 client MUST ensure uniquely identifies a given KeyPackage object 1092 among the set of KeyPackages created by this client. 1094 The value for hpke_init_key MUST be a public key for the asymmetric 1095 encryption scheme defined by cipher_suite. The whole structure is 1096 signed using the client's signature key. A KeyPackage object with an 1097 invalid signature field MUST be considered malformed. The input to 1098 the signature computation comprises all of the fields except for the 1099 signature field. 1101 enum { 1102 reserved(0), 1103 mls10(1), 1104 (255) 1105 } ProtocolVersion; 1107 // See IANA registry for registered values 1108 uint16 ExtensionType; 1110 struct { 1111 ExtensionType extension_type; 1112 opaque extension_data<0..2^16-1>; 1113 } Extension; 1115 struct { 1116 ProtocolVersion version; 1117 CipherSuite cipher_suite; 1118 HPKEPublicKey hpke_init_key; 1119 Credential credential; 1120 Extension extensions<8..2^32-1>; 1121 opaque signature<0..2^16-1>; 1122 } KeyPackage; 1124 KeyPackage objects MUST contain at least two extensions, one of type 1125 "capabilities", and one of type "lifetime". The "capabilities" 1126 extension allow MLS session establishment to be safe from downgrade 1127 attacks on the parameters described (as discussed in Section 10), 1128 while still only advertising one version / ciphersuite per 1129 KeyPackage. 1131 As the "KeyPackage" is a structure which is stored in the Ratchet 1132 Tree and updated depending on the evolution of this tree, each 1133 modification of its content MUST be reflected by a change of its 1134 signature. This allow other members to control the validity of the 1135 KeyPackage at any time and in particular in the case of a newcomer 1136 joining the group. 1138 7.1. Client Capabilities 1140 The "capabilities" extension indicates what protocol versions, 1141 ciphersuites, and protocol extensions are supported by a client. 1143 struct { 1144 ProtocolVersion versions<0..255>; 1145 CipherSuite ciphersuites<0..255>; 1146 ExtensionType extensions<0..255>; 1147 } Capabilities; 1148 This extension MUST be always present in a KeyPackage. Extensions 1149 that appear in the "extensions" field of a KeyPackage MUST be 1150 included in the "extensions" field of the "capabilities" extension. 1152 7.2. Lifetime 1154 The "lifetime" extension represents the times between which clients 1155 will consider a KeyPackage valid. This time is represented as an 1156 absolute time, measured in seconds since the Unix epoch 1157 (1970-01-01T00:00:00Z). A client MUST NOT use the data in a 1158 KeyPackage for any processing before the "not_before" date, or after 1159 the "not_after" date. 1161 uint64 not_before; 1162 uint64 not_after; 1164 Applications MUST define a maximum total lifetime that is acceptable 1165 for a KeyPackage, and reject any KeyPackage where the total lifetime 1166 is longer than this duration. 1168 This extension MUST always be present in a KeyPackage. 1170 7.3. KeyPackage Identifiers 1172 Within MLS, a KeyPackage is identified by its hash (see, e.g., 1173 Section 11.2.2). The "key_id" extension allows applications to add 1174 an explicit, application-defined identifier to a KeyPackage. 1176 opaque key_id<0..2^16-1>; 1178 7.4. Parent Hash 1180 The "parent_hash" extension serves to bind a KeyPackage to all the 1181 nodes above it in the group's ratchet tree. This enforces the tree 1182 invariant, meaning that malicious members can't lie about the state 1183 of the ratchet tree when they send Welcome messages to new members. 1185 opaque parent_hash<0..255>; 1187 This extension MUST be present in all Updates that are sent as part 1188 of a Commit message. If the extension is present, clients MUST 1189 verify that "parent_hash" matches the hash of the leaf's parent node 1190 when represented as a ParentNode struct. 1192 7.5. Tree Hashes 1194 To allow group members to verify that they agree on the public 1195 cryptographic state of the group, this section defines a scheme for 1196 generating a hash value that represents the contents of the group's 1197 ratchet tree and the members' KeyPackages. 1199 The hash of a tree is the hash of its root node, which we define 1200 recursively, starting with the leaves. 1202 Elements of the ratchet tree are called "Node" objects and the leaves 1203 contain an optional "KeyPackage", while the parents contain an 1204 optional "ParentNode". 1206 struct { 1207 uint8 present; 1208 select (present) { 1209 case 0: struct{}; 1210 case 1: T value; 1211 } 1212 } optional; 1214 struct { 1215 HPKEPublicKey public_key; 1216 uint32 unmerged_leaves<0..2^32-1>; 1217 opaque parent_hash<0..255>; 1218 } ParentNode; 1220 When computing the hash of a parent node, the "ParentNodeHashInput" 1221 structure is used: 1223 struct { 1224 uint32 node_index; 1225 optional parent_node; 1226 opaque left_hash<0..255>; 1227 opaque right_hash<0..255>; 1228 } ParentNodeHashInput; 1230 The "left_hash" and "right_hash" fields hold the hashes of the node's 1231 left and right children, respectively. When computing the hash of a 1232 leaf node, the hash of a "LeafNodeHashInput" object is used: 1234 struct { 1235 uint32 node_index; 1236 optional key_package; 1237 } LeafNodeHashInput; 1238 Note that the "node_index" field contains the index of the leaf among 1239 the nodes in the tree, not its index among the leaves; "node_index = 1240 2 * leaf_index". 1242 7.6. Group State 1244 Each member of the group maintains a GroupContext object that 1245 summarizes the state of the group: 1247 struct { 1248 opaque group_id<0..255>; 1249 uint64 epoch; 1250 opaque tree_hash<0..255>; 1251 opaque confirmed_transcript_hash<0..255>; 1252 Extension extensions<0..2^32-1>; 1253 } GroupContext; 1255 The fields in this state have the following semantics: 1257 * The "group_id" field is an application-defined identifier for the 1258 group. 1260 * The "epoch" field represents the current version of the group key. 1262 * The "tree_hash" field contains a commitment to the contents of the 1263 group's ratchet tree and the credentials for the members of the 1264 group, as described in Section 7.5. 1266 * The "confirmed_transcript_hash" field contains a running hash over 1267 the messages that led to this state. 1269 When a new member is added to the group, an existing member of the 1270 group provides the new member with a Welcome message. The Welcome 1271 message provides the information the new member needs to initialize 1272 its GroupContext. 1274 Different changes to the group will have different effects on the 1275 group state. These effects are described in their respective 1276 subsections of Section 11.1. The following general rules apply: 1278 * The "group_id" field is constant 1280 * The "epoch" field increments by one for each Commit message that 1281 is processed 1283 * The "tree_hash" is updated to represent the current tree and 1284 credentials 1286 * The "confirmed_transcript_hash" is updated with the data for an 1287 MLSPlaintext message encoding a Commit message in two parts: 1289 struct { 1290 opaque group_id<0..255>; 1291 uint64 epoch; 1292 Sender sender; 1293 ContentType content_type = commit; 1294 Commit commit; 1295 opaque signature<0..2^16-1>; 1296 } MLSPlaintextCommitContent; 1298 struct { 1299 MAC confirmation_tag; 1300 } MLSPlaintextCommitAuthData; 1302 interim_transcript_hash_[0] = ""; // zero-length octet string 1304 confirmed_transcript_hash_[n] = 1305 Hash(interim_transcript_hash_[n] || 1306 MLSPlaintextCommitContent_[n]); 1308 interim_transcript_hash_[n+1] = 1309 Hash(confirmed_transcript_hash_[n] || 1310 MLSPlaintextCommitAuthData_[n]); 1312 Thus the "confirmed_transcript_hash" field in a GroupContext object 1313 represents a transcript over the whole history of MLSPlaintext Commit 1314 messages, up to the confirmation tag field in the current 1315 MLSPlaintext message. The confirmation tag is then included in the 1316 transcript for the next epoch. The interim transcript hash is passed 1317 to new members in the GroupInfo struct, and enables existing members 1318 to incorporate a Commit message into the transcript without having to 1319 store the whole MLSPlaintextCommitAuthData structure. 1321 As shown above, when a new group is created, the 1322 "interim_transcript_hash" field is set to the zero-length octet 1323 string. 1325 7.7. Update Paths 1327 As described in Section 11.2, each MLS Commit message may optionally 1328 transmit a KeyPackage leaf and node values along its direct path. 1329 The path contains a public key and encrypted secret value for all 1330 intermediate nodes in the path above the leaf. The path is ordered 1331 from the closest node to the leaf to the root; each node MUST be the 1332 parent of its predecessor. 1334 struct { 1335 opaque kem_output<0..2^16-1>; 1336 opaque ciphertext<0..2^16-1>; 1337 } HPKECiphertext; 1339 struct { 1340 HPKEPublicKey public_key; 1341 HPKECiphertext encrypted_path_secret<0..2^32-1>; 1342 } UpdatePathNode; 1344 struct { 1345 KeyPackage leaf_key_package; 1346 UpdatePathNode nodes<0..2^32-1>; 1347 } UpdatePath; 1349 For each "UpdatePathNode", the resolution of the corresponding copath 1350 node MUST be filtered by removing all new leaf nodes added as part of 1351 this MLS Commit message. The number of ciphertexts in the 1352 "encrypted_path_secret" vector MUST be equal to the length of the 1353 filtered resolution, with each ciphertext being the encryption to the 1354 respective resolution node. 1356 The HPKECiphertext values are computed as 1358 kem_output, context = SetupBaseS(node_public_key, "") 1359 ciphertext = context.Seal(group_context, path_secret) 1361 where "node_public_key" is the public key of the node that the path 1362 secret is being encrypted for, group_context is the current 1363 GroupContext object for the group, and the functions "SetupBaseS" and 1364 "Seal" are defined according to [I-D.irtf-cfrg-hpke]. 1366 Decryption is performed in the corresponding way, using the private 1367 key of the resolution node and the ephemeral public key transmitted 1368 in the message. 1370 8. Key Schedule 1372 Group keys are derived using the "Extract" and "Expand" functions 1373 from the KDF for the group's ciphersuite, as well as the functions 1374 defined below: 1376 ExpandWithLabel(Secret, Label, Context, Length) = 1377 KDF.Expand(Secret, KDFLabel, Length) 1379 Where KDFLabel is specified as: 1381 struct { 1382 uint16 length = Length; 1383 opaque label<7..255> = "mls10 " + Label; 1384 opaque context<0..2^32-1> = Context; 1385 } KDFLabel; 1387 DeriveSecret(Secret, Label) = 1388 ExpandWithLabel(Secret, Label, "", KDF.Nh) 1390 The value "KDF.Nh" is the size of an output from "KDF.Extract", in 1391 bytes. In the below diagram: 1393 * KDF.Extract takes its salt argument from the top and its IKM 1394 argument from the left 1396 * DeriveSecret takes its Secret argument from the incoming arrow 1398 When processing a handshake message, a client combines the following 1399 information to derive new epoch secrets: 1401 * The init secret from the previous epoch 1403 * The commit secret for the current epoch 1405 * The GroupContext object for current epoch 1407 Given these inputs, the derivation of secrets for an epoch proceeds 1408 as shown in the following diagram: 1410 init_secret_[n-1] 1411 | 1412 V 1413 commit_secret -> KDF.Extract = joiner_secret 1414 | 1415 V 1416 Derive-Secret(., "member") 1417 | 1418 V 1419 psk_secret (or 0) -> KDF.Extract = member_secret 1420 | 1421 +--> Derive-Secret(., "welcome") 1422 | = welcome_secret 1423 | 1424 V 1425 ExpandWithLabel(., "epoch", GroupContext_[n], KDF.Nh) 1426 | 1427 V 1428 epoch_secret 1429 | 1430 +--> Derive-Secret(.,