idnits 2.17.1 draft-barnes-mls-protocol-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 02, 2018) is 2275 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.rescorla-mls-architecture' is mentioned on line 189, but not defined == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-27 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 J. Millican 5 Expires: August 6, 2018 Facebook 6 E. Omara 7 Google 8 K. Cohn-Gordon 9 University of Oxford 10 R. Robert 11 Wire 12 February 02, 2018 14 The Messaging Layer Security (MLS) Protocol 15 draft-barnes-mls-protocol-00 17 Abstract 19 Messaging applications are increasingly making use of end-to-end 20 security mechanisms to ensure that messages are only accessible to 21 the communicating endpoints, and not to any servers involved in 22 delivering messages. Establishing keys to provide such protections 23 is challenging for group chat settings, in which more than two 24 participants need to agree on a key but may not be online at the same 25 time. In this document, we specify a key establishment protocol that 26 provides efficient asynchronous group key establishment with forward 27 secrecy and post-compromise security for groups in size ranging from 28 two to thousands. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Binary Trees . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Merkle Trees . . . . . . . . . . . . . . . . . . . . . . 11 71 5.2.1. Merkle Proofs . . . . . . . . . . . . . . . . . . . . 12 72 5.3. Ratchet Trees . . . . . . . . . . . . . . . . . . . . . . 12 73 5.3.1. Blank Ratchet Tree Nodes . . . . . . . . . . . . . . 13 74 6. Group State . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.1. Cryptographic Objects . . . . . . . . . . . . . . . . . . 15 76 6.1.1. Curve25519 with SHA-256 . . . . . . . . . . . . . . . 15 77 6.1.2. P-256 with SHA-256 . . . . . . . . . . . . . . . . . 16 78 6.2. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 17 79 7. Initialization Keys . . . . . . . . . . . . . . . . . . . . . 18 80 7.1. UserInitKey . . . . . . . . . . . . . . . . . . . . . . . 18 81 7.2. GroupInitKey . . . . . . . . . . . . . . . . . . . . . . 19 82 8. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Init . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 8.2. GroupAdd . . . . . . . . . . . . . . . . . . . . . . . . 22 85 8.3. UserAdd . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 8.4. Update . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 8.5. Delete . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 9. Sequencing of State Changes . . . . . . . . . . . . . . . . . 25 89 9.1. Server-side enforced ordering . . . . . . . . . . . . . . 26 90 9.2. Client-side enforced ordering . . . . . . . . . . . . . . 26 91 10. Message Protection . . . . . . . . . . . . . . . . . . . . . 26 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 11.1. Confidentiality of the Group Secrets . . . . . . . . . . 28 94 11.2. Authentication . . . . . . . . . . . . . . . . . . . . . 28 95 11.3. Forward and post-compromise security . . . . . . . . . . 28 96 11.4. Init Key Reuse . . . . . . . . . . . . . . . . . . . . . 29 97 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 99 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 14.1. Normative References . . . . . . . . . . . . . . . . . . 30 101 14.2. Informative References . . . . . . . . . . . . . . . . . 30 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 104 1. Introduction 106 DISCLAIMER: This is a work-in-progress draft of MLS and has not yet 107 seen significant security analysis. It should not be used as a basis 108 for building production systems. 110 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 111 draft is maintained in GitHub. Suggested changes should be submitted 112 as pull requests at https://github.com/ekr/mls-protocol. 113 Instructions are on that page as well. Editorial changes can be 114 managed in GitHub, but any substantive change should be discussed on 115 the MLS mailing list. 117 Groups of agents who want to send each other encrypted messages need 118 a way to derive shared symmetric encryption keys. For two parties, 119 this problem has been studied thoroughly, with the Double Ratchet 120 emerging as a common solution [doubleratchet] [signal]. Channels 121 implementing the Double Ratchet enjoy fine-grained forward secrecy as 122 well as post-compromise security, but are nonetheless efficient 123 enough for heavy use over low-bandwidth networks. 125 For groups of size greater than two, a common strategy is to 126 unilaterally broadcast symmetric "sender" keys over existing shared 127 symmetric channels, and then for each agent to send messages to the 128 group encrypted with their own sender key. Unfortunately, while this 129 improves efficiency over pairwise broadcast of individual messages 130 and (with the addition of a hash ratchet) provides forward secrecy, 131 it is difficult to achieve post-compromise security with sender keys. 132 An adversary who learns a sender key can often indefinitely and 133 passively eavesdrop on that sender's messages. Generating and 134 distributing a new sender key provides a form of post-compromise 135 security with regard to that sender. However, it requires 136 computation and communications resources that scale linearly as the 137 size of the group. 139 In this document, we describe a protocol based on tree structures 140 that enable asynchronous group keying with forward secrecy and post- 141 compromise security. The use of "asynchronous ratcheting trees" 142 [art] allows the members of the group to derive and update shared 143 keys with costs that scale as the log of the group size. The use of 144 Merkle trees to store identity information allows strong 145 authentication of group membership, again with logarithmic cost. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 [TODO: The architecture document uses "Client" instead of 154 "Participant". Harmonize terminology.] 156 Participant: An agent that uses this protocol to establish shared 157 cryptographic state with other participants. A participant is 158 defined by the cryptographic keys it holds. An application may 159 use one participant per device (keeping keys local to each device) 160 or sync keys among a user's devices so that each user appears as a 161 single participant. 163 Group: A collection of participants with shared cryptographic state. 165 Member: A participant that is included in the shared state of a 166 group, and has access to the group's secrets. 168 Initialization Key: A short-lived Diffie-Hellman key pair used to 169 introduce a new member to a group. Initialization keys can be 170 published for both individual participants (UserInitKey) and 171 groups (GroupInitKey). 173 Leaf Key: A short-lived Diffie-Hellman key pair that represents a 174 group member's contribution to the group secret, so called because 175 the participants leaf keys are the leaves in the group's ratchet 176 tree. 178 Identity Key: A long-lived signing key pair used to authenticate the 179 sender of a message. 181 Terminology specific to tree computations is described in Section 5. 183 We use the TLS presentation language [I-D.ietf-tls-tls13] to describe 184 the structure of protocol messages. 186 3. Basic Assumptions 188 This protocol is designed to execute in the context of a Messaging 189 Service (MS) as described in [I-D.rescorla-mls-architecture]. In 190 particular, we assume the MS provides the following services: 192 o A long-term identity key provider which allows participants to 193 authenticate protocol messages in a group. These keys MUST be 194 kept for the lifetime of the group as there is no mechanism in the 195 protocol for changing a participant's identity key. 197 o A broadcast channel, for each group, which will relay a message to 198 all members of a group. For the most part, we assume that this 199 channel delivers messages in the same order to all participants. 200 (See Section 9 for further considerations.) 202 o A directory to which participants can publish initialization keys, 203 and from which participant can download initialization keys for 204 other participants. 206 4. Protocol Overview 208 The goal of this protocol is to allow a group of participants to 209 exchange confidential and authenticated messages. It does so by 210 deriving a sequence of keys known only to group members. Keys should 211 be secret against an active network adversary and should have both 212 forward and post-compromise secrecy with respect to compromise of a 213 participant. 215 We describe the information stored by each participant as a _state_, 216 which includes both public and private data. An initial state, 217 including an initial set of participants, is set up by a group 218 creator using the _Init_ algorithm and based on information pre- 219 published by the initial members. The creator sends the _GroupInit_ 220 message to the participants, who can then set up their own group 221 state and derive the same shared key. Participants then exchange 222 messages to produce new shared states which are causally linked to 223 their predecessors, forming a logical Directed Acyclic Graph (DAG) of 224 states. Participants can send _Update_ messages for post-compromise 225 secrecy and new participants can be added or existing participants 226 removed from the group. 228 The protocol algorithms we specify here follow. Each algorithm 229 specifies both (i) how a participant performs the operation and (ii) 230 how other participants update their state based on it. 232 There are four major operations in the lifecycle of a group: 234 o Adding a member, initiated by a current member 236 o Adding a member, initiated by the new member 238 o Key update 239 o Removal of a member 241 Before the initialization of a group, participants publish 242 UserInitKey objects to a directory provided to the Messaging Service. 244 Group 245 A B C Directory Channel 246 | | | | | 247 | UserInitKeyA | | | | 248 |------------------------------------------->| | 249 | | | | | 250 | | UserInitKeyB | | | 251 | |---------------------------->| | 252 | | | | | 253 | | | UserInitKeyC | | 254 | | |------------->| | 255 | | | | | 257 When a participant A wants to establish a group with B and C, it 258 first downloads InitKeys for B and C. It then initializes a group 259 state containing only itself and uses the InitKeys to compute 260 GroupAdd messages to add B and C, in a sequence chosen by A. These 261 messages are broadcasted to the Group, and processed in sequence by B 262 and C. Messages received before a participant has joined the group 263 are ignored. Only after A has received its GroupAdd messages back 264 from the server does it update its state to reflect their addition. 266 Group 267 A B C Directory Channel 268 | | | | | 269 | UserInitKeyB, UserInitKeyC | | 270 |<-------------------------------------------| | 271 | | | | | 272 | | | | GroupAdd(A->AB) | 273 |--------------------------------------------------------------->| 274 | | | | | 275 | | | | GroupAdd(AB->ABC) | 276 |--------------------------------------------------------------->| 277 | | | | | 278 | | | | GroupAdd(A->AB) | 279 |<---------------------------------------------------------------| 280 |state.add(B) |<------------------------------------------------| 281 | |state.init() |x---------------------------------| 282 | | | | | 283 | | | | GroupAdd(AB->ABC) | 284 |<---------------------------------------------------------------| 285 |state.add(C) |<------------------------------------------------| 286 | |state.add(C) |<---------------------------------| 287 | | |state.init() | | 288 | | | | | 290 Subsequent additions of group members proceed in the same way. Any 291 member of the group can download an InitKey for a new participant and 292 broadcast a GroupAdd which the current group can use to update their 293 state and the new participant can use to initialize its state. 295 It is sometimes necessary for a new participant to join without an 296 explicit invitation from a current member. For example, if a user 297 that is authorized to be in the group logs in on a new device, that 298 device will need to join the group as a new participant, but will not 299 have been invited. 301 In these "user-initiated join" cases, the "InitKey + Add message" 302 flow is reversed. We assume that at some previous point, a group 303 member has published a GroupInitKey reflecting the current state of 304 the group (A, B, C). The new participant Z downloads that 305 GroupInitKey from the directory, generates a UserAdd message, and 306 broadcasts it to the group. Once current members process this 307 message, they will have a shared state that also includes Z. 309 Group 310 A B ... Z Directory Channel 311 | GroupInitKey | | | | 312 |------------------------------------------->| | 313 | | | | | 314 ~ ~ ~ ~ ~ 315 | | | | | 316 | | | GroupInitKey | | 317 | | |<-------------| | 318 | | | | | 319 | | | UserAdd(.->D)| | 320 | | |---------------------------->| 321 | | | | | 322 | | | | UserAdd(.->D)| 323 |<----------------------------------------------------------| 324 |state.add(D) |<-------------------------------------------| 325 | |state.add(D) |<----------------------------| 326 | | |state.init() | | 327 | | | | | 329 To enforce forward secrecy and post-compromise security of messages, 330 each participant periodically updates its leaf key, the DH key pair 331 that represents its contribution to the group key. Any member of the 332 group can send an Update at any time by generating a fresh leaf key 333 pair and sending an Update message that describes how to update the 334 group key with that new key pair. Once all participants have 335 processed this message, the group's secrets will be unknown to an 336 attacker that had compromised the sender's prior DH leaf private key. 338 It is left to the application to determine the interval of time 339 between Update messages. This policy could require a change for each 340 message, or it could require sending an update every week or more. 342 Group 343 A B ... Z Directory Channel 344 | | | | | 345 | Update(A) | | | | 346 |---------------------------------------------------------->| 347 | | | | | 348 | | | | Update(A) | 349 |<----------------------------------------------------------| 350 |state.upd(D) |<-------------------------------------------| 351 | |state.upd(D) |<----------------------------| 352 | | |state.upd(A) | | 353 | | | | | 355 Users are deleted from the group in a similar way, as a key update is 356 effectively removing the old leaf from the group. Any member of the 357 group can generate a Delete message that adds new entropy to the 358 group state that is known to all members except the deleted member. 359 After other participants have processed this message, the group's 360 secrets will be unknown to the deleted participant. Note that this 361 does not necessarily imply that any member is actually allowed to 362 evict other members; groups can layer authentication-based access 363 control policies on top of these basic mechanism. 365 Group 366 A B ... Z Directory Channel 367 | | | | | 368 | | | Delete(B) | | 369 | | |---------------------------->| 370 | | | | | 371 | | | | Delete(B) | 372 |<----------------------------------------------------------| 373 |state.del(B) | |<----------------------------| 374 | | |state.del(B) | | 375 | | | | | 376 | | | | | 378 5. Binary Trees 380 The protocol uses two types of binary tree structures: 382 o Merkle trees for efficiently committing to a set of group 383 participants. 385 o Asynchronous ratcheting trees for deriving shared secrets among 386 this group of participants. 388 The two trees in the protocol share a common structure, allowing us 389 to maintain a direct mapping between their nodes when manipulating 390 group membership. The "nth" leaf in each tree is owned by the "nth" 391 group participant. 393 5.1. Terminology 395 We use a common set of terminology to refer to both types of binary 396 tree. 398 Trees consist of various different types of _nodes_. A node is a 399 _leaf_ if it has no children, and a _parent_ otherwise; note that all 400 parents in our Merkle or asynchronous ratcheting trees have precisely 401 two children, a _left_ child and a _right_ child. A node is the 402 _root_ of a tree if it has no parents, and _intermediate_ if it has 403 both children and parents. The _descendants_ of a node are that 404 node, its children, and the descendants of its children, and we say a 405 tree _contains_ a node if that node is a descendant of the root of 406 the tree. Nodes are _siblings_ if they share the same parent. 408 A _subtree_ of a tree is the tree given by the descendants of any 409 node, the _head_ of the subtree The _size_ of a tree or subtree is 410 the number of leaf nodes it contains. For a given parent node, its 411 _left subtree_ is the subtree with its left child as head 412 (respectively _right subtree_). 414 All trees used in this protocol are left-balanced binary trees. A 415 binary tree is _full_ (and _balanced_) if it its size is a power of 416 two and for any parent node in the tree, its left and right subtrees 417 have the same size. If a subtree is full and it is not a subset of 418 any other full subtree, then it is _maximal_. 420 A binary tree is _left-balanced_ if for every parent, either the 421 parent is balanced, or the left subtree of that parent is the largest 422 full subtree that could be constructed from the leaves present in the 423 parent's own subtree. Note that given a list of "n" items, there is 424 a unique left-balanced binary tree structure with these elements as 425 leaves. In such a left-balanced tree, the "k-th" leaf node refers to 426 the "k-th" leaf node in the tree when counting from the left, 427 starting from 0. 429 The _direct path_ of a root is the empty list, and of any other node 430 is the concatenation of that node with the direct path of its parent. 431 The _copath_ of a node is the list of siblings of nodes in its direct 432 path, excluding the root, which has no sibling. The _frontier_ of a 433 tree is the list of heads of the maximal full subtrees of the tree, 434 ordered from left to right. 436 For example, in the below tree: 438 o The direct path of C is (C, CD, ABCD) 440 o The copath of C is (D, AB, EFG) 442 o The frontier of the tree is (ABCD, EF, G) 443 ABCDEFG 444 / \ 445 / \ 446 / \ 447 ABCD EFG 448 / \ / \ 449 / \ / \ 450 AB CD EF \ 451 / \ / \ / \ \ 452 A B C D E F G 454 We extend both types of tree to include a concept of "blank" nodes; 455 which are used to replace group members who have been removed. We 456 expand on how these are used and implemented in the sections below. 458 (Note that left-balanced binary trees are the same structure that is 459 used for the Merkle trees in the Certificate Transparency protocol 460 [I-D.ietf-trans-rfc6962-bis].) 462 5.2. Merkle Trees 464 Merkle trees are used to efficiently commit to a collection of group 465 members. We require a hash function, denoted H, to construct this 466 tree. 468 Each node in a Merkle tree is the output of the hash function, 469 computed as follows: 471 o Leaf nodes: "H( 0x01 || leaf-value )" 473 o Parent nodes: "H( 0x02 || left-value || right-value)" 475 o Blank leaf nodes: "H( 0x00 )" 477 The below tree provides an example of a size 2 tree, containing 478 identity keys "A" and "B". 480 * H(2 || H(1 || A) || H(1 || B)) 481 / \ 482 / \ 483 H(1 || A) * * H(1 || B) 485 In Merkle trees, blank nodes appear only at the leaves. In 486 computation of intermediate nodes, they are treated in the same way 487 as other nodes. 489 5.2.1. Merkle Proofs 491 A proof of a given leaf being a member of the Merkle tree consists of 492 the value of the leaf node, as well as the values of each node in its 493 copath. From these values, its path to the root can be verified; 494 proving the inclusion of the leaf in the Merkle tree. 496 In the below tree, we denote with a star the Merkle proof of 497 membership for leaf node "A". For brevity, we notate "Hash(0x02 || 498 A || B)" as "AB". 500 ABCD 501 / \ 502 AB CD* 503 / \ / \ 504 A B* C D 506 5.3. Ratchet Trees 508 Ratchet trees are used for generating shared group secrets. These 509 are constructed as a series of Diffie-Hellman keys in a binary tree 510 arrangement, with each user knowing their direct path, and thus being 511 able to compute the shared root secret. 513 To construct these trees, we require: 515 o a Diffie-Hellman finite-field group or elliptic curve; 517 o a Derive-Key-Pair function that produces a key pair from an octet 518 string, such as the output of a DH computation 520 Each node in a ratchet tree contains up to three values: 522 o A secret octet string (optional) 524 o A DH private key (optional) 526 o A DH public key 528 To compute the private values (secret and private key) for a given 529 node, one must first know the private key from one of its children, 530 and the public key from the other child. Then the value of the 531 parent is computed as follows: 533 o secret = DH(L, R) 535 o private, public = Derive-Key-Pair(secret) 536 Ratchet trees are constructed as left-balanced trees, defined such 537 that each parent node's key pair is derived from the Diffie-Hellman 538 shared secret of its two child nodes. To compute the root secret and 539 private key, a participant must know the public keys of nodes in its 540 copath, as well as its own leaf private key. 542 For example, the ratchet tree consisting of the private keys (A, B, 543 C, D) is constructed as follows: 545 DH(DH(AB), DH(CD)) 546 / \ 547 DH(AB) DH(CD) 548 / \ / \ 549 A B C D 551 Ratchet trees constructed this way provide the property that one must 552 hold at least one private key from the tree to compute the secret 553 root key. With all participants holding one leaf private key; this 554 allows any individual to update their own key and change the shared 555 root key, such that only group members can compute the new key. 557 5.3.1. Blank Ratchet Tree Nodes 559 Nodes in a ratchet tree can have a special value "_", used to 560 indicate that the node should be ignored during path computations. 561 Such nodes are used to replace leaves when participants are deleted 562 from the group. 564 If any node in the copath of a leaf is _, it should be ignored during 565 the computation of the path. For example, the tree consisting of the 566 private keys (A, _, C, D) is constructed as follows: 568 DH(A, DH(CD)) 569 / \ 570 A DH(CD) 571 / \ / \ 572 A _ C D 574 If two sibling nodes are both _, their parent value also becomes _. 576 Blank nodes effectively result in an unbalanced tree, but allow the 577 tree management to behave as for a balanced tree for programming 578 simplicity. 580 6. Group State 582 The state of an MLS group at a given time comprises: 584 o A group identifier (GID) 586 o A ciphersuite used for cryptographic computations 588 o A Merkle tree over the participants' identity keys 590 o A ratchet tree over the participants' leaf key pairs 592 o A message master secret (known only to participants) 594 o An add key pair (private key known only to participants) 596 o An init secret (known only to participants) 598 Since a group can evolve over time, a session logically comprises a 599 sequence of states. The time in which each individual state is used 600 is called an "epoch", and each state is assigned an epoch number that 601 increments when the state changes. 603 MLS handshake messages provide each node with enough information 604 about the trees to authenticate messages within the group and compute 605 the group secrets. 607 Thus, each participant will need to store the following information 608 about each state of the group: 610 1. The participant's index in the identity/ratchet trees 612 2. The private key associated with the participant's leaf public 613 key 615 3. The private key associated with the participant's identity 616 public key 618 4. The current epoch number 620 5. The group identifier (GID) 622 6. A subset of the identity tree comprising at least the copath for 623 the participant's leaf 625 7. A subset of the ratchet tree comprising at least the copath for 626 the participant's leaf 628 8. The current message encryption shared secret, called the master 629 secret 631 9. The current add key pair 633 10. The current init secret 635 6.1. Cryptographic Objects 637 Each MLS session uses a single ciphersuite that specifies the 638 following primitives to be used in group key computations: 640 o A hash function 642 o A Diffie-Hellman finite-field group or elliptic curve 644 The ciphersuite must also specify an algorithm "Derive-Key-Pair" that 645 maps octet strings with the same length as the output of the hash 646 function to key pairs for the Diffie-Hellman group. 648 Public keys and Merkle tree nodes used in the protocol are opaque 649 values in a format defined by the ciphersuite, using the following 650 four types: 652 uint16 CipherSuite; 653 opaque DHPublicKey<1..2^16-1>; 654 opaque SignaturePublicKey<1..2^16-1>; 655 opaque MerkleNode<1..255> 657 [[OPEN ISSUE: In some cases we will want to include a raw key when we 658 sign and in others we may want to include an identity or a 659 certificate containing the key. This type needs to be extended to 660 accommodate that.]] 662 6.1.1. Curve25519 with SHA-256 664 This ciphersuite uses the following primitives: 666 o Hash function: SHA-256 668 o Diffie-Hellman group: Curve25519 [RFC7748] 670 Given an octet string X, the private key produced by the Derive-Key- 671 Pair operation is SHA-256(X). (Recall that any 32-octet string is a 672 valid Curve25519 private key.) The corresponding public key is 673 X25519(SHA-256(X), 9). 675 Implementations SHOULD use the approach specified in [RFC7748] to 676 calculate the Diffie-Hellman shared secret. Implementations MUST 677 check whether the computed Diffie-Hellman shared secret is the all- 678 zero value and abort if so, as described in Section 6 of [RFC7748]. 679 If implementers use an alternative implementation of these elliptic 680 curves, they SHOULD perform the additional checks specified in 681 Section 7 of {{RFC7748]} 683 6.1.2. P-256 with SHA-256 685 This ciphersuite uses the following primitives: 687 o Hash function: SHA-256 689 o Diffie-Hellman group: secp256r1 (NIST P-256) 691 Given an octet string X, the private key produced by the Derive-Key- 692 Pair operation is SHA-256(X), interpreted as a big-endian integer. 693 The corresponding public key is the result of multiplying the 694 standard P-256 base point by this integer. 696 P-256 ECDH calculations (including parameter and key generation as 697 well as the shared secret calculation) are performed according to 698 [IEEE1363] using the ECKAS-DH1 scheme with the identity map as key 699 derivation function (KDF), so that the shared secret is the 700 x-coordinate of the ECDH shared secret elliptic curve point 701 represented as an octet string. Note that this octet string (Z in 702 IEEE 1363 terminology) as output by FE2OSP, the Field Element to 703 Octet String Conversion Primitive, has constant length for any given 704 field; leading zeros found in this octet string MUST NOT be 705 truncated. 707 (Note that this use of the identity KDF is a technicality. The 708 complete picture is that ECDH is employed with a non-trivial KDF 709 because MLS does not directly use this secret for anything other than 710 for computing other secrets.) 712 Clients MUST validate remote public values by ensuring that the point 713 is a valid point on the elliptic curve. The appropriate validation 714 procedures are defined in Section 4.3.7 of [X962] and alternatively 715 in Section 5.6.2.3 of [keyagreement]. This process consists of three 716 steps: (1) verify that the value is not the point at infinity (O), 717 (2) verify that for Y = (x, y) both integers are in the correct 718 interval, (3) ensure that (x, y) is a correct solution to the 719 elliptic curve equation. For these curves, implementers do not need 720 to verify membership in the correct subgroup. 722 6.2. Key Schedule 724 Group keys are derived using the HKDF-Extract and HKDF-Expand 725 functions as defined in [RFC5869], as well as the functions defined 726 below: 728 Derive-Secret(Secret, Label, ID, Epoch, Msg) = 729 HKDF-Expand(Secret, HkdfLabel, Length) 731 Where HkdfLabel is specified as: 733 struct { 734 uint16 length = Length; 735 opaque label<7..255> = "mls10 " + Label; 736 opaque group_id<0..2^16-1> = ID; 737 uint32 epoch = Epoch; 738 opaque message<1..2^16-1> = Msg 739 } HkdfLabel; 741 The Hash function used by HKDF is the ciphersuite hash algorithm. 742 Hash.length is its output length in bytes. In the below diagram: 744 o HKDF-Extract takes its Salt argument form the top and its IKM 745 argument from the left 747 o Derive-Secret takes its Secret argument from the incoming arrow 749 When processing a handshake message, a participant combines the 750 following information to derive new epoch secrets: 752 o The init secret from the previous epoch 754 o The update secret for the current epoch 756 o The handshake message that caused the epoch change 758 o The current group identifier (GID) and epoch 760 The derivation of the update secret depends on the change being made, 761 as described below. 763 For UserAdd or GroupAdd, the new user does not know the prior epoch 764 init secret. Instead, entropy from the prior epoch is added via the 765 update secret, and an all-zero vector with the same length as a hash 766 output is used in the place of the init secret. 768 Given these inputs, the derivation of secrets for an epoch proceeds 769 as shown in the following diagram: 771 Init Secret [n-1] (or 0) 772 | 773 V 774 Update Secret -> HKDF-Extract = Epoch Secret 775 | 776 | 777 +--> Derive-Secret(., "msg", ID, Epoch, Msg) 778 | = message_master_secret 779 | 780 +--> Derive-Secret(., "add", ID, Epoch, Msg) 781 | | 782 | V 783 | Derive-Key-Pair(.) = Add Key Pair 784 | 785 V 786 Derive-Secret(., "init", ID, Epoch, Msg) 787 | 788 V 789 Init Secret [n] 791 7. Initialization Keys 793 In order to facilitate asynchronous addition of participants to a 794 group, it is possible to pre-publish initialization keys that provide 795 some public information about a user or group. UserInitKey messages 796 provide information about a potential group member, that a group 797 member can use to add this user to a group without asynchronously. 798 GroupInitKey messages provide information about a group that a new 799 user can use to join the group without any of the existing members of 800 the group being online. 802 7.1. UserInitKey 804 A UserInitKey object specifies what ciphersuites a client supports, 805 as well as providing public keys that the client can use for key 806 derivation and signing. The client's identity key is intended to be 807 stable throughout the lifetime of the group; there is no mechanism to 808 change it. Init keys are intended to be used a very limited number 809 of times, potentially once. (see Section 11.4). 811 The init_keys array MUST have the same length as the cipher_suites 812 array, and each entry in the init_keys array MUST be a public key for 813 the DH group defined by the corresponding entry in the cipher_suites 814 array. 816 The whole structure is signed using the client's identity key. A 817 UserInitKey object with an invalid signature field MUST be considered 818 malformed. The input to the signature computation comprises all of 819 the fields except for the signature field. 821 struct { 822 CipherSuite cipher_suites<0..255>; 823 DHPublicKey init_keys<1..2^16-1>; 824 SignaturePublicKey identity_key; 825 SignatureScheme algorithm; 826 opaque signature<0..2^16-1>; 827 } UserInitKey; 829 7.2. GroupInitKey 831 A GroupInitKey object specifies the aspects of a group's state that a 832 new member needs to initialize its state (together with an identity 833 key and a fresh leaf key pair). 835 o The current epoch number 837 o The number of participants currently in the group 839 o The group ID 841 o The cipher suite used by the group 843 o The public key of the current update key pair for the group 845 o The frontier of the identity tree, as a sequence of hash values 847 o The frontier of the ratchet tree, as a sequence of public keys 849 GroupInitKey messages are not themselves signed. A GroupInitKey 850 should not be published "bare"; instead, it should be published by 851 constructing a handshake message with type "none", which will include 852 a signature by a member of the group and a proof of membership in the 853 group. 855 struct { 856 uint32 epoch; 857 uint32 group_size; 858 opaque group_id<0..2^16-1>; 859 CipherSuite cipher_suite; 860 DHPublicKey add_key; 861 MerkleNode identity_frontier<0..2^16-1>; 862 DHPublicKey ratchet_frontier<0..2^16-1>; 863 } GroupInitKey; 865 8. Handshake Messages 867 Over the lifetime of a group, its state will change for: 869 o Group initialization 871 o A current member adding a new participant 873 o A new participant adding themselves 875 o A current participant updating its leaf key 877 o A current member deleting another current member 879 In MLS, these changes are accomplished by broadcasting "handshake" 880 messages to the group. Note that unlike TLS and DTLS, there is not a 881 consolidated handshake phase to the protocol. Rather, handshake 882 messages are exchanged throughout the lifetime of a group, whenever a 883 change is made to the group state. 885 An MLS handshake message encapsulates a specific message that 886 accomplishes a change to the group state. It also includes two other 887 important features: 889 o A GroupInitKey so that a new participant can observe the latest 890 state of the handshake and initialize itself 892 o A signature by a member of the group, together with a Merkle 893 inclusion proof that demonstrates that the signer is a legitimate 894 member of the group. 896 Before considering a handshake message valid, the recipient MUST 897 verify both that the signature is valid, the Merkle inclusion proof 898 is valid, and the sender is authorized to make the change according 899 to group policy. The input to the signature computations comprises 900 the entire handshake message except for the signature field. 902 The Merkle tree head to be used for validating the inclusion proof 903 MUST be one that the recipient trusts to represent the current list 904 of participant identity keys. 906 enum { 907 none(0), 908 init(1), 909 user_add(2), 910 group_add(3), 911 update(4), 912 delete(5), 913 (255) 914 } HandshakeType; 916 struct { 917 HandshakeType msg_type; 918 uint24 inner_length; 919 select (Handshake.msg_type) { 920 case none: struct{}; 921 case init: Init; 922 case user_add: UserAdd; 923 case group_add: GroupAdd; 924 case update: Update; 925 case delete: Delete; 926 }; 928 uint32 prior_epoch; 929 GroupInitKey init_key; 931 uint32 signer_index; 932 MerkleNode identity_proof<1..2^16-1>; 933 SignaturePublicKey identity_key; 935 SignatureScheme algorithm; 936 opaque signature<1..2^16-1>; 937 } Handshake; 939 [[ OPEN ISSUE: There will be a need to integrate credentials from an 940 authentication service that associate identities to the identity keys 941 used to sign messages. This integration will enable meaningful 942 authentication (of identities, rather than keys), and will need to be 943 done in such a way as to prevent unknown key share attacks. ]] 945 [[ OPEN ISSUE: The GroupAdd and Delete operations create a "double- 946 join" situation, where a participants leaf key is also known to 947 another participant. When a participant A is double-joined to 948 another B, deleting A will not remove them from the conversation, 949 since they will still hold the leaf key for B. These situations are 950 resolved by updates, but since operations are asynchronous and 951 participants may be offline for a long time, the group will need to 952 be able to maintain security in the presence of double-joins. ]] 954 [[ OPEN ISSUE: It is not possible for the recipient of a handshake 955 message to verify that ratchet tree information in the message is 956 accurate, because each node can only compute the secret and private 957 key for nodes in its direct path. This creates the possibility that 958 a malicious participant could cause a denial of service by sending a 959 handshake message with invalid values for public keys in the ratchet 960 tree. ]] 962 8.1. Init 964 [[ OPEN ISSUE: Direct initialization is currently undefined. A 965 participant can create a group by initializing its own state to 966 reflect a group including only itself, then adding the initial 967 participants. This has computation and communication complexity O(N 968 log N) instead of the O(N) complexity of direct initialization. ]] 970 8.2. GroupAdd 972 A GroupAdd message is sent by a group member to add a new participant 973 to the group. The content of the message is only the UserInitKey for 974 the user being added. 976 struct { 977 UserInitKey init_key; 978 } GroupAdd; 980 A group member generates such a message by requesting from the 981 directory a UserInitKey for the user to be added. The new 982 participant processes the message together with the private key 983 corresponding to the UserInitKey to initialize his state as follows: 985 o Compute the participant's leaf key pair by combining the init key 986 in the UserInitKey with the prior epoch's add key pair 988 o Use the frontiers in the GroupInitKey of the Handshake message to 989 add its keys to the trees 991 An existing participant receiving a GroupAdd message first verifies 992 the signature on the message, then verifies its identity proof 993 against the identity tree held by the participant. The participant 994 then updates its state as follows: 996 o Compute the new participant's leaf key pair by combining the leaf 997 key in the UserInitKey with the prior epoch add key pair 999 o Update the group's identity tree and ratchet tree with the new 1000 participant's information 1002 The update secret resulting from this change is the output of a DH 1003 computation between the private key for the root of the ratchet tree 1004 and the add public key from the previous epoch. 1006 [[ ALTERNATIVE: The sender could also generate the new participant's 1007 leaf using a fresh key pair, as opposed to a key pair derived from 1008 the prior epoch's secret. This would reduce the "double-join" 1009 problem, at the cost of the GroupAdd having to include a new ratchet 1010 frontier. ]] 1012 8.3. UserAdd 1014 A UserAdd message is sent by a new group participant to add 1015 themselves to the group, based on having already had access to a 1016 GroupInitKey for the group. 1018 struct { 1019 DHPublicKey add_path<1..2^16-1>; 1020 } UserAdd; 1022 A new participant generates this message using the following steps: 1024 o Fetch a GroupInitKey for the group 1026 o Use the frontiers in the GroupInitKey to add its keys to the trees 1028 o Compute the direct path from the new participant's leaf in the new 1029 ratchet tree (the add_path). 1031 An existing participant receiving a UserAdd first verifies the 1032 signature on the message, then verifies its identity inclusion proof 1033 against the updated identity tree expressed in the GroupInitKey of 1034 the Handshake message (since the signer is not included in the prior 1035 group state held by the existing participant). The participant then 1036 updates its state as follows: 1038 o Update trees with the descriptions in the new GroupInitKey 1040 o Update the local ratchet tree with the add path in the UserAdd 1041 message, replacing any common nodes with the values in the add 1042 path 1044 The update secret resulting from this change is the output of a DH 1045 computation between the private key for the root of the ratchet tree 1046 and the add public key from the previous epoch. 1048 8.4. Update 1050 An Update message is sent by a group participant to update its leaf 1051 key pair. This operation provides post-compromise security with 1052 regard to the participant's prior leaf private key. 1054 struct { 1055 DHPublicKey ratchetPath<1..2^16-1>; 1056 } Update; 1058 The sender of an Update message creates it in the following way: 1060 o Generate a fresh leaf key pair 1062 o Compute its direct path in the current ratchet tree 1064 An existing participant receiving a Update message first verifies the 1065 signature on the message, then verifies its identity proof against 1066 the identity tree held by the participant. The participant then 1067 updates its state as follows: 1069 o Update the cached ratchet tree by replacing nodes in the direct 1070 path from the updated leaf with the corresponding nodes in the 1071 Update message 1073 The update secret resulting from this change is the secret for the 1074 root node of the ratchet tree. 1076 8.5. Delete 1078 A delete message is sent by a group member to remove one or more 1079 participants from the group. 1081 struct { 1082 uint32 deleted; 1083 DHPublicKey path<1..2^16-1>; 1084 } Delete; 1086 The sender of a Delete message must know the deleted node's copath. 1087 Based on this knowledge, it computes a Delete message as follows: 1089 o Generate a fresh leaf key pair 1091 o Compute the direct path from the deleted node's index with the 1092 fresh leaf key pair in the current ratchet tree 1094 An existing participant receiving a Update message first verifies the 1095 signature on the message, then verifies its identity proof against 1096 the identity tree held by the participant. The participant then 1097 updates its state as follows: 1099 o Update the cached ratchet tree by replacing nodes in the direct 1100 path from the deleted leaf with the corresponding nodes in the 1101 Update message 1103 o Update the cached ratchet tree and identity tree by replacing the 1104 deleted node's leaves with blank nodes 1106 The update secret resulting from this change is the secret for the 1107 root node of the ratchet tree after both updates. 1109 9. Sequencing of State Changes 1111 [[ OPEN ISSUE: This section has an initial set of considerations 1112 regarding sequencing. It would be good to have some more detailed 1113 discussion, and hopefully have a mechanism to deal with this issue. 1114 ]] 1116 Each handshake message is premised on a given starting state, 1117 indicated in its "prior_epoch" field. If the changes implied by a 1118 handshake messages are made starting from a different state, the 1119 results will be incorrect. 1121 This need for sequencing is not a problem as long as each time a 1122 group member sends a handshake message, it is based on the most 1123 current state of the group. In practice, however, there is a risk 1124 that two members will generate handshake messages simultaneously, 1125 based on the same state. 1127 When this happens, there is a need for the members of the group to 1128 deconflict the simultaneous handshake messages. There are two 1129 general approaches: 1131 o Have the delivery service enforce a total order 1133 o Have a signal in the message that clients can use to break ties 1135 In either case, there is a risk of starvation. In a sufficiently 1136 busy group, a given member may never be able to send a handshake 1137 message, because he always loses to other members. The degree to 1138 which this is a practical problem will depend on the dynamics of the 1139 application. 1141 Regardless of how messages are kept in sequence, implementations MUST 1142 only update their cryptographic state when valid handshake messages 1143 are received. Generation of handshake messages MUST be stateless, 1144 since the endpoint cannot know at that time whether the change 1145 implied by the handshake message will succeed or not. 1147 9.1. Server-side enforced ordering 1149 With this approach, the delivery service ensures that incoming 1150 messages are added to an ordered queue and outgoing messages are 1151 dispatched in the same order. The server is trusted to resolve 1152 conflicts during race-conditions (when two members send a message at 1153 the same time), as the server doesn't have any additional knowledge 1154 thanks to the confidentiality of the messages. 1156 Messages should have a counter field sent in clear-text that can be 1157 checked by the server and used for tie-breaking. The counter starts 1158 at 0 and is incremented for every new incoming message. If two group 1159 members send a message with the same counter, the first message to 1160 arrive will be accepted by the server and the second one will be 1161 rejected. The rejected message needs to be sent again with the 1162 correct counter number. 1164 To prevent counter manipulation by the server, the counter's 1165 integrity can be ensured by including the counter in a signed message 1166 envelope. 1168 This applies to all messages, not only state changing messages. 1170 9.2. Client-side enforced ordering 1172 Order enforcement can be implemented on the client as well, one way 1173 to achieve it is to use a two step update protocol: the first client 1174 sends a proposal to update and the proposal is accepted when it gets 1175 50%+ approval from the rest of the group, then it sends the approved 1176 update. Clients which didn't get their proposal accepted, will wait 1177 for the winner to send their update before retrying new proposals. 1179 While this seems safer as it doesn't rely on the server, it is more 1180 complex and harder to implement. It also could cause starvation for 1181 some clients if they keep failing to get their proposal accepted. 1183 [[OPEN ISSUE: Another possibility here is batching + deterministic 1184 selection.]] 1186 10. Message Protection 1188 [[ OPEN ISSUE: This section has initial considerations about message 1189 protection. This issue clearly needs more specific recommendations, 1190 possibly a protocol specification in this document or a separate one. 1191 ]] 1192 The primary purpose of this protocol is to enable an authenticated 1193 group key exchange among participants. In order to protect messages 1194 sent among those participants, an application will need to specify 1195 how messages are protected. 1197 For every epoch, the root key of the ratcheting tree can be used to 1198 derive key material for symmetric operations such as encryption/AEAD 1199 and MAC; AEAD or MAC MUST be used to ensure that the message 1200 originated from a member of the group. 1202 In addition, asymmetric signatures SHOULD be used to authenticate the 1203 sender of a message. 1205 In combination with server-side enforced ordering, data from previous 1206 messages is used (as a salt when hashing) to: 1208 o add freshness to derived symmetric keys 1210 o cryptographically bind the transcript of all previous messages 1211 with the current group shared secret 1213 Possible candidates for that are: 1215 o the key used for the previous message (hash ratcheting) 1217 o the counter of the previous message (needs to be known to new 1218 members of the group) 1220 o the hash of the previous message (proof that other participants 1221 saw the same history) 1223 The requirement for this is that all participants know these values. 1224 If additional clear-text fields are attached to messages (like the 1225 counter), those fields MUST be protected by a signed message 1226 envelope. 1228 Alternatively, the hash of the previous message can also be included 1229 as an additional field rather than change the encryption key. This 1230 allows for a more flexible approach, because the receiving party can 1231 choose to ignore it (if the value is not known, or if transcript 1232 security is not required). 1234 11. Security Considerations 1236 The security goals of MLS are described in [[the architecture doc]]. 1237 We describe here how the protocol achieves its goals at a high level, 1238 though a complete security analysis is outside of the scope of this 1239 document. 1241 11.1. Confidentiality of the Group Secrets 1243 Group secrets are derived from (i) previous group secrets, and (ii) 1244 the root key of a ratcheting tree. Only group members know their 1245 leaf private key in the group, therefore, the root key of the group's 1246 ratcheting tree is secret and thus so are all values derived from it. 1248 Initial leaf keys are known only by their owner and the group 1249 creator, because they are derived from an authenticated key exchange 1250 protocol. Subsequent leaf keys are known only by their owner. 1251 [[TODO: or by someone who replaced them.]] 1253 Note that the long-term identity keys used by the protocol MUST be 1254 distributed by an "honest" authentication service for parties to 1255 authenticate their legitimate peers. 1257 11.2. Authentication 1259 There are two forms of authentication we consider. The first form 1260 considers authentication with respect to the group. That is, the 1261 group members can verify that a message originated from one of the 1262 members of the group. This is implicitly guaranteed by the secrecy 1263 of the shared key derived from the ratcheting trees: if all members 1264 of the group are honest, then the shared group key is only known to 1265 the group members. By using AEAD or appropriate MAC with this shared 1266 key, we can guarantee that a participant in the group (who knows the 1267 shared secret key) has sent a message. 1269 The second form considers authentication with respect to the sender, 1270 meaning the group members can verify that a message originated from a 1271 particular member of the group. This property is provided by digital 1272 signatures on the messages under identity keys. 1274 [[ OPEN ISSUE: Signatures under the identity keys, while simple, have 1275 the side-effect of preclude deniability. We may wish to allow other 1276 options, such as (ii) a key chained off of the identity key, or (iii) 1277 some other key obtained through a different manner, such as a 1278 pairwise channel that provides deniability for the message 1279 contents.]] 1281 11.3. Forward and post-compromise security 1283 Message encryption keys are derived via a hash ratchet, which 1284 provides a form of forward secrecy: learning a message key does not 1285 reveal previous message or root keys. Post-compromise security is 1286 provided by Update operations, in which a new root key is generated 1287 from the latest ratcheting tree. If the adversary cannot derive the 1288 updated root key after an Update operation, it cannot compute any 1289 derived secrets. 1291 11.4. Init Key Reuse 1293 Initialization keys are intended to be used only once and then 1294 deleted. Reuse of init keys is not believed to be inherently 1295 insecure [dhreuse], although it can complicate protocol analyses. 1297 12. IANA Considerations 1299 TODO: Registries for protocol parameters, e.g., ciphersuites 1301 13. Contributors 1303 o Benjamin Beurdouche 1304 INRIA 1305 benjamin.beurdouche@ens.fr 1307 o Karthikeyan Bhargavan 1308 INRIA 1309 karthikeyan.bhargavan@inria.fr 1311 o Cas Cremers 1312 University of Oxford 1313 cas.cremers@cs.ox.ac.uk 1315 o Alan Duric 1316 Wire 1317 alan@wire.com 1319 o Srinivas Inguva 1320 Twitter 1321 singuva@twitter.com 1323 o Albert Kwon 1324 MIT 1325 kwonal@mit.edu 1327 o Eric Rescorla 1328 Mozilla 1329 ekr@rtfm.com 1331 o Thyla van der Merwe 1332 Royal Holloway, University of London 1333 thyla.van.der@merwe.tech 1335 14. References 1337 14.1. Normative References 1339 [I-D.ietf-tls-tls13] 1340 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1341 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 1342 January 2018. 1344 [IEEE1363] 1345 "IEEE Standard Specifications for Password-Based Public- 1346 Key Cryptographic Techniques", IEEE standard, 1347 DOI 10.1109/ieeestd.2009.4773330, n.d.. 1349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1350 Requirement Levels", BCP 14, RFC 2119, 1351 DOI 10.17487/RFC2119, March 1997, 1352 . 1354 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1355 Key Derivation Function (HKDF)", RFC 5869, 1356 DOI 10.17487/RFC5869, May 2010, 1357 . 1359 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1360 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1361 2016, . 1363 [X962] ANSI, "Public Key Cryptography For The Financial Services 1364 Industry: The Elliptic Curve Digital Signature Algorithm 1365 (ECDSA)", ANSI X9.62, 1998. 1367 14.2. Informative References 1369 [art] Cohn-Gordon, K., Cremers, C., Garratt, L., Millican, J., 1370 and K. Milner, "On Ends-to-Ends Encryption: Asynchronous 1371 Group Messaging with Strong Security Guarantees", January 1372 2018, . 1374 [dhreuse] Menezes, A. and B. Ustaoglu, "On reusing ephemeral keys in 1375 Diffie-Hellman key agreement protocols", International 1376 Journal of Applied Cryptography Vol. 2, pp. 154, 1377 DOI 10.1504/ijact.2010.038308, 2010. 1379 [doubleratchet] 1380 Cohn-Gordon, K., Cremers, C., Dowling, B., Garratt, L., 1381 and D. Stebila, "A Formal Security Analysis of the Signal 1382 Messaging Protocol", 2017 IEEE European Symposium on 1383 Security and Privacy (EuroS&P), 1384 DOI 10.1109/eurosp.2017.27, April 2017. 1386 [I-D.ietf-trans-rfc6962-bis] 1387 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 1388 Stradling, "Certificate Transparency Version 2.0", draft- 1389 ietf-trans-rfc6962-bis-27 (work in progress), October 1390 2017. 1392 [keyagreement] 1393 Barker, E., Chen, L., Roginsky, A., and M. Smid, 1394 "Recommendation for Pair-Wise Key Establishment Schemes 1395 Using Discrete Logarithm Cryptography", National Institute 1396 of Standards and Technology report, 1397 DOI 10.6028/nist.sp.800-56ar2, May 2013. 1399 [signal] (ed), T. and M. Marlinspike, "The Double Ratchet 1400 Algorithm", n.d., 1401 . 1404 Authors' Addresses 1406 Richard Barnes 1407 Cisco 1409 Email: rlb@ipv.sx 1411 Jon Millican 1412 Facebook 1414 Email: jmillican@fb.com 1416 Emad Omara 1417 Google 1419 Email: emadomara@google.com 1420 Katriel Cohn-Gordon 1421 University of Oxford 1423 Email: me@katriel.co.uk 1425 Raphael Robert 1426 Wire 1428 Email: raphael@wire.com