< draft-ietf-mls-protocol-06.txt   draft-ietf-mls-protocol-07.txt >
Network Working Group R. Barnes Network Working Group R. Barnes
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational J. Millican Intended status: Informational B. Beurdouche
Expires: December 1, 2019 Facebook Expires: January 9, 2020 Inria
J. Millican
Facebook
E. Omara E. Omara
Google Google
K. Cohn-Gordon K. Cohn-Gordon
University of Oxford University of Oxford
R. Robert R. Robert
Wire Wire
May 30, 2019 July 08, 2019
The Messaging Layer Security (MLS) Protocol The Messaging Layer Security (MLS) Protocol
draft-ietf-mls-protocol-06 draft-ietf-mls-protocol-07
Abstract Abstract
Messaging applications are increasingly making use of end-to-end Messaging applications are increasingly making use of end-to-end
security mechanisms to ensure that messages are only accessible to security mechanisms to ensure that messages are only accessible to
the communicating endpoints, and not to any servers involved in the communicating endpoints, and not to any servers involved in
delivering messages. Establishing keys to provide such protections delivering messages. Establishing keys to provide such protections
is challenging for group chat settings, in which more than two is challenging for group chat settings, in which more than two
clients need to agree on a key but may not be online at the same clients need to agree on a key but may not be online at the same
time. In this document, we specify a key establishment protocol that time. In this document, we specify a key establishment protocol that
skipping to change at page 1, line 46 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 7 3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. Ratchet Trees . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Ratchet Trees . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Tree Computation Terminology . . . . . . . . . . . . . . 10 5.1. Tree Computation Terminology . . . . . . . . . . . . . . 10
5.2. Ratchet Tree Nodes . . . . . . . . . . . . . . . . . . . 13 5.2. Ratchet Tree Nodes . . . . . . . . . . . . . . . . . . . 13
5.3. Views of a Ratchet Tree . . . . . . . . . . . . . . . . . 14 5.3. Views of a Ratchet Tree . . . . . . . . . . . . . . . . . 14
5.4. Ratchet Tree Updates . . . . . . . . . . . . . . . . . . 15 5.4. Ratchet Tree Updates . . . . . . . . . . . . . . . . . . 15
5.5. Synchronizing Views of the Tree . . . . . . . . . . . . . 16 5.5. Synchronizing Views of the Tree . . . . . . . . . . . . . 16
6. Cryptographic Objects . . . . . . . . . . . . . . . . . . . . 17 6. Cryptographic Objects . . . . . . . . . . . . . . . . . . . . 17
6.1. Curve25519, SHA-256, and AES-128-GCM . . . . . . . . . . 18 6.1. Curve25519, SHA-256, and AES-128-GCM . . . . . . . . . . 18
6.1.1. P-256, SHA-256, and AES-128-GCM . . . . . . . . . . . 18 6.1.1. P-256, SHA-256, and AES-128-GCM . . . . . . . . . . . 19
6.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Tree Hashes . . . . . . . . . . . . . . . . . . . . . . . 20 6.3. Tree Hashes . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. Group State . . . . . . . . . . . . . . . . . . . . . . . 21 6.4. Group State . . . . . . . . . . . . . . . . . . . . . . . 21
6.5. Direct Paths . . . . . . . . . . . . . . . . . . . . . . 23 6.5. Direct Paths . . . . . . . . . . . . . . . . . . . . . . 23
6.6. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 24 6.6. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 24
6.7. Encryption Keys . . . . . . . . . . . . . . . . . . . . . 25 6.7. Encryption Keys . . . . . . . . . . . . . . . . . . . . . 26
7. Initialization Keys . . . . . . . . . . . . . . . . . . . . . 28 7. Initialization Keys . . . . . . . . . . . . . . . . . . . . . 27
8. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 29 8. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Metadata Encryption . . . . . . . . . . . . . . . . . . . 31 8.1. Metadata Encryption . . . . . . . . . . . . . . . . . . . 30
8.2. Content Signing and Encryption . . . . . . . . . . . . . 32 8.2. Content Signing and Encryption . . . . . . . . . . . . . 31
9. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 32 9. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 32
9.1. Init . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Init . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2. Add . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.2. Add . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4. Remove . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.4. Remove . . . . . . . . . . . . . . . . . . . . . . . . . 38
10. Sequencing of State Changes . . . . . . . . . . . . . . . . . 39 10. Sequencing of State Changes . . . . . . . . . . . . . . . . . 39
10.1. Server-Enforced Ordering . . . . . . . . . . . . . . . . 40 10.1. Server-Enforced Ordering . . . . . . . . . . . . . . . . 40
10.2. Client-Enforced Ordering . . . . . . . . . . . . . . . . 40 10.2. Client-Enforced Ordering . . . . . . . . . . . . . . . . 41
10.3. Merging Updates . . . . . . . . . . . . . . . . . . . . 40 10.3. Merging Updates . . . . . . . . . . . . . . . . . . . . 41
11. Application Messages . . . . . . . . . . . . . . . . . . . . 41 11. Application Messages . . . . . . . . . . . . . . . . . . . . 42
11.1. Message Encryption and Decryption . . . . . . . . . . . 42 11.1. Tree of Application Secrets . . . . . . . . . . . . . . 43
11.2. Delayed and Reordered Application messages . . . . . . . 43 11.2. Sender Ratchets . . . . . . . . . . . . . . . . . . . . 44
12. Security Considerations . . . . . . . . . . . . . . . . . . . 44 11.3. Deletion Schedule . . . . . . . . . . . . . . . . . . . 44
12.1. Confidentiality of the Group Secrets . . . . . . . . . . 44 11.4. Further Restrictions . . . . . . . . . . . . . . . . . . 46
12.2. Authentication . . . . . . . . . . . . . . . . . . . . . 44 11.5. Message Encryption and Decryption . . . . . . . . . . . 46
12.3. Forward and post-compromise security . . . . . . . . . . 45 11.6. Delayed and Reordered Application messages . . . . . . . 48
12.4. Init Key Reuse . . . . . . . . . . . . . . . . . . . . . 45 12. Security Considerations . . . . . . . . . . . . . . . . . . . 48
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 12.1. Confidentiality of the Group Secrets . . . . . . . . . . 48
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 12.2. Authentication . . . . . . . . . . . . . . . . . . . . . 48
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 12.3. Forward and post-compromise security . . . . . . . . . . 49
15.1. Normative References . . . . . . . . . . . . . . . . . . 46 12.4. Init Key Reuse . . . . . . . . . . . . . . . . . . . . . 49
15.2. Informative References . . . . . . . . . . . . . . . . . 47 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
Appendix A. Tree Math . . . . . . . . . . . . . . . . . . . . . 48 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
15.1. Normative References . . . . . . . . . . . . . . . . . . 50
15.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Tree Math . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
DISCLAIMER: This is a work-in-progress draft of MLS and has not yet DISCLAIMER: This is a work-in-progress draft of MLS and has not yet
seen significant security analysis. It should not be used as a basis seen significant security analysis. It should not be used as a basis
for building production systems. for building production systems.
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Suggested changes should be submitted draft is maintained in GitHub. Suggested changes should be submitted
as pull requests at https://github.com/mlswg/mls-protocol. as pull requests at https://github.com/mlswg/mls-protocol.
skipping to change at page 4, line 21 skipping to change at page 4, line 25
compromise security. Based on earlier work on "asynchronous compromise security. Based on earlier work on "asynchronous
ratcheting trees" [art], the mechanism presented here use a ratcheting trees" [art], the mechanism presented here use a
asynchronous key-encapsulation mechanism for tree structures. This asynchronous key-encapsulation mechanism for tree structures. This
mechanism allows the members of the group to derive and update shared mechanism allows the members of the group to derive and update shared
keys with costs that scale as the log of the group size. keys with costs that scale as the log of the group size.
1.1. Change Log 1.1. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION. RFC EDITOR PLEASE DELETE THIS SECTION.
draft-07
o Initial version of the Tree based Application Key Schedule (*)
o Initial definition of the Init message for group creation (*)
o Fix issue with the transcript used for newcomers (*)
o Clarifications on message framing and HPKE contexts (*)
draft-06 draft-06
o Reorder blanking and update in the Remove operation (*) o Reorder blanking and update in the Remove operation (*)
o Rename the GroupState structure to GroupContext (*) o Rename the GroupState structure to GroupContext (*)
o Rename UserInitKey to ClientInitKey o Rename UserInitKey to ClientInitKey
o Resolve the circular dependency that draft-05 introduced in the o Resolve the circular dependency that draft-05 introduced in the
confirmation MAC calculation (*) confirmation MAC calculation (*)
skipping to change at page 18, line 31 skipping to change at page 18, line 31
X25519_SHA256_AES128GCM(0x0001), X25519_SHA256_AES128GCM(0x0001),
(0xFFFF) (0xFFFF)
} CipherSuite; } CipherSuite;
6.1. Curve25519, SHA-256, and AES-128-GCM 6.1. Curve25519, SHA-256, and AES-128-GCM
This ciphersuite uses the following primitives: This ciphersuite uses the following primitives:
o Hash function: SHA-256 o Hash function: SHA-256
o Diffie-Hellman group: Curve25519 [RFC7748]
o AEAD: AES-128-GCM o AEAD: AES-128-GCM
When HPKE is used with this ciphersuite, it uses the following
algorithms:
o KEM: 0x0002 = DHKEM(Curve25519)
o KDF: 0x0001 = HKDF-SHA256
o AEAD: 0x0001 = AES-GCM-128
Given an octet string X, the private key produced by the Derive-Key- Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-256(X). (Recall that any 32-octet string is a Pair operation is SHA-256(X). (Recall that any 32-octet string is a
valid Curve25519 private key.) The corresponding public key is valid Curve25519 private key.) The corresponding public key is
X25519(SHA-256(X), 9). X25519(SHA-256(X), 9).
Implementations SHOULD use the approach specified in [RFC7748] to Implementations SHOULD use the approach specified in [RFC7748] to
calculate the Diffie-Hellman shared secret. Implementations MUST calculate the Diffie-Hellman shared secret. Implementations MUST
check whether the computed Diffie-Hellman shared secret is the all- check whether the computed Diffie-Hellman shared secret is the all-
zero value and abort if so, as described in Section 6 of [RFC7748]. zero value and abort if so, as described in Section 6 of [RFC7748].
If implementers use an alternative implementation of these elliptic If implementers use an alternative implementation of these elliptic
curves, they SHOULD perform the additional checks specified in curves, they SHOULD perform the additional checks specified in
Section 7 of [RFC7748] Section 7 of [RFC7748]
6.1.1. P-256, SHA-256, and AES-128-GCM 6.1.1. P-256, SHA-256, and AES-128-GCM
This ciphersuite uses the following primitives: This ciphersuite uses the following primitives:
o Hash function: SHA-256 o Hash function: SHA-256
o Diffie-Hellman group: secp256r1 (NIST P-256)
o AEAD: AES-128-GCM o AEAD: AES-128-GCM
When HPKE is used with this ciphersuite, it uses the following
algorithms:
o KEM: 0x0001 = DHKEM(P-256)
o KDF: 0x0001 = HKDF-SHA256
o AEAD: 0x0001 = AES-GCM-128
Given an octet string X, the private key produced by the Derive-Key- Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-256(X), interpreted as a big-endian integer. Pair operation is SHA-256(X), interpreted as a big-endian integer.
The corresponding public key is the result of multiplying the The corresponding public key is the result of multiplying the
standard P-256 base point by this integer. standard P-256 base point by this integer.
P-256 ECDH calculations (including parameter and key generation as P-256 ECDH calculations (including parameter and key generation as
well as the shared secret calculation) are performed according to well as the shared secret calculation) are performed according to
[IEEE1363] using the ECKAS-DH1 scheme with the identity map as key [IEEE1363] using the ECKAS-DH1 scheme with the identity map as key
derivation function (KDF), so that the shared secret is the derivation function (KDF), so that the shared secret is the
x-coordinate of the ECDH shared secret elliptic curve point x-coordinate of the ECDH shared secret elliptic curve point
skipping to change at page 22, line 9 skipping to change at page 22, line 9
6.4. Group State 6.4. Group State
Each member of the group maintains a GroupContext object that Each member of the group maintains a GroupContext object that
summarizes the state of the group: summarizes the state of the group:
struct { struct {
opaque group_id<0..255>; opaque group_id<0..255>;
uint32 epoch; uint32 epoch;
opaque tree_hash<0..255>; opaque tree_hash<0..255>;
opaque transcript_hash<0..255>; opaque confirmed_transcript_hash<0..255>;
} GroupContext; } GroupContext;
The fields in this state have the following semantics: The fields in this state have the following semantics:
o The "group_id" field is an application-defined identifier for the o The "group_id" field is an application-defined identifier for the
group. group.
o The "epoch" field represents the current version of the group key. o The "epoch" field represents the current version of the group key.
o The "tree_hash" field contains a commitment to the contents of the o The "tree_hash" field contains a commitment to the contents of the
group's rachet tree and the credentials for the members of the group's rachet tree and the credentials for the members of the
group, as described in Section 6.3. group, as described in Section 6.3.
o The "transcript_hash" field contains the list of "GroupOperation" o The "confirmed_transcript_hash" field contains a running hash over
messages that led to this state. the handshake messages that led to this state.
When a new member is added to the group, an existing member of the When a new member is added to the group, an existing member of the
group provides the new member with a Welcome message. The Welcome group provides the new member with a Welcome message. The Welcome
message provides the information the new member needs to initialize message provides the information the new member needs to initialize
its GroupContext. its GroupContext.
Different group operations will have different effects on the group Different group operations will have different effects on the group
state. These effects are described in their respective subsections state. These effects are described in their respective subsections
of Section 9. The following rules apply to all operations: of Section 9. The following rules apply to all operations:
o The "group_id" field is constant o The "group_id" field is constant
o The "epoch" field increments by one for each GroupOperation that o The "epoch" field increments by one for each GroupOperation that
is processed is processed
o The "tree_hash" is updated to represent the current tree and o The "tree_hash" is updated to represent the current tree and
credentials credentials
o The "transcript_hash" is updated with the data for an MLSPlaintext o The "confirmed_transcript_hash" is updated with the data for an
message encoding a group operation in two parts: MLSPlaintext message encoding a group operation in two parts:
struct { struct {
opaque group_id<0..255>; opaque group_id<0..255>;
uint32 epoch; uint32 epoch;
uint32 sender; uint32 sender;
ContentType content_type = handshake; ContentType content_type = handshake;
GroupOperation operation; GroupOperation operation;
} MLSPlaintextOpContent; } MLSPlaintextOpContent;
struct { struct {
opaque confirmation<0..255>; opaque confirmation<0..255>;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} MLSPlaintextOpAuthData; } MLSPlaintextOpAuthData;
intermediate_hash_[n] = Hash(transcript_hash_[n-1] || MLSPlaintextOpAuthData_[n-1]); confirmed_transcript_hash_[n] =
transcript_hash_[n] = Hash(intermediate_hash_[n] || MLSPlaintextOpContent_[n]); Hash(interim_transcript_hash_[n-1] ||
MLSPlaintextOpContent_[n]);
interim_transcript_hash_[n] =
Hash(confirmed_transcript_hash_[n] ||
MLSPlaintextOpAuthData_[n]);
This structure incorporates everything in an MLSPlaintext up to the This structure incorporates everything in an MLSPlaintext up to the
confirmation field in the transcript that is included in that confirmation field in the transcript that is included in that
confirmation field (via the GroupContext). The confirmation and confirmation field (via the GroupContext). The confirmation and
signature fields are then included in the transcript for the next signature fields are then included in the transcript for the next
operation. The intermediate hash enables implementations to in operation. The interim transcript hash is passed to new members in
corporate a plaintext into the transcript without having to store the the WelcomeInfo struct, and enables existing members to incorporate a
handshake message into the transcript without having to store the
whole MLSPlaintextOpAuthData structure. whole MLSPlaintextOpAuthData structure.
When a new one-member group is created (which requires no When a new one-member group is created (which requires no
GroupOperation), the "transcript_hash" field is set to an all-zero GroupOperation), the "interim_transcript_hash" field is set to the
vector of length Hash.length, where the Hash algorithm is defined by zero-length octet string.
the ciphersuite.
6.5. Direct Paths 6.5. Direct Paths
As described in Section 5.4, each MLS message needs to transmit node As described in Section 5.4, each MLS message needs to transmit node
values along the direct path of a leaf. The path contains a public values along the direct path of a leaf. The path contains a public
key for the leaf node, and a public key and encrypted secret value key for the leaf node, and a public key and encrypted secret value
for intermediate nodes in the path. In both cases, the path is for intermediate nodes in the path. In both cases, the path is
ordered from the leaf to the root; each node MUST be the parent of ordered from the leaf to the root; each node MUST be the parent of
its predecessor. its predecessor.
skipping to change at page 24, line 26 skipping to change at page 24, line 26
DirectPathNode nodes<0..2^16-1>; DirectPathNode nodes<0..2^16-1>;
} DirectPath; } DirectPath;
The length of the "encrypted_path_secret" vector MUST be zero for the The length of the "encrypted_path_secret" vector MUST be zero for the
first node in the path. For the remaining elements in the vector, first node in the path. For the remaining elements in the vector,
the number of ciphertexts in the "encrypted_path_secret" vector MUST the number of ciphertexts in the "encrypted_path_secret" vector MUST
be equal to the length of the resolution of the corresponding copath be equal to the length of the resolution of the corresponding copath
node. Each ciphertext in the list is the encryption to the node. Each ciphertext in the list is the encryption to the
corresponding node in the resolution. corresponding node in the resolution.
The HPKECiphertext values are computed according to the Encrypt The HPKECiphertext values are computed as
function defined in [I-D.barnes-cfrg-hpke].
ephemeral_key, context = SetupBaseI(node_public_key, "")
ciphertext = context.Seal("", path_secret)
where "node_public_key" is the public key of the node that the path
secret is being encrypted for, and the functions "SetupBaseI" and
"Seal" are defined according to [I-D.irtf-cfrg-hpke].
Decryption is performed in the corresponding way, using the private Decryption is performed in the corresponding way, using the private
key of the resolution node and the ephemeral public key transmitted key of the resolution node and the ephemeral public key transmitted
in the message. in the message.
6.6. Key Schedule 6.6. Key Schedule
Group keys are derived using the HKDF-Extract and HKDF-Expand Group keys are derived using the HKDF-Extract and HKDF-Expand
functions as defined in [RFC5869], as well as the functions defined functions as defined in [RFC5869], as well as the functions defined
below: below:
HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand-Label(Secret, Label, Context, Length) =
HKDF-Expand(Secret, HkdfLabel, Length) HKDF-Expand(Secret, HkdfLabel, Length)
Where HkdfLabel is specified as: Where HkdfLabel is specified as:
struct { struct {
uint16 length = Length; opaque group_context<0..255> = Hash(GroupContext_[n]);
opaque label<7..255> = "mls10 " + Label; uint16 length = Length;
opaque context<0..2^32-1> = Context; opaque label<7..255> = "mls10 " + Label;
opaque context<0..2^32-1> = Context;
} HkdfLabel; } HkdfLabel;
Derive-Secret(Secret, Label, Context) = Derive-Secret(Secret, Label) =
HKDF-Expand-Label(Secret, Label, Hash(Context), Hash.length) HKDF-Expand-Label(Secret, Label, "", Hash.length)
The Hash function used by HKDF is the ciphersuite hash algorithm. The Hash function used by HKDF is the ciphersuite hash algorithm.
Hash.length is its output length in bytes. In the below diagram: Hash.length is its output length in bytes. In the below diagram:
o HKDF-Extract takes its salt argument from the top and its IKM o HKDF-Extract takes its salt argument from the top and its IKM
argument from the left argument from the left
o Derive-Secret takes its Secret argument from the incoming arrow o Derive-Secret takes its Secret argument from the incoming arrow
When processing a handshake message, a client combines the following When processing a handshake message, a client combines the following
skipping to change at page 26, line 35 skipping to change at page 27, line 17
handshake_key_[sender] = handshake_key_[sender] =
HKDF-Expand-Label(handshake_secret, "hs key", [sender], key_length) HKDF-Expand-Label(handshake_secret, "hs key", [sender], key_length)
Here the value [sender] represents the index of the member that will Here the value [sender] represents the index of the member that will
use this key to send, encoded as a uint32. use this key to send, encoded as a uint32.
For application messages, a chain of keys is derived for each sender For application messages, a chain of keys is derived for each sender
in a similar fashion. This allows forward secrecy at the level of in a similar fashion. This allows forward secrecy at the level of
application messages within and out of an epoch. A step in this application messages within and out of an epoch. A step in this
chain (the second subscript) is called a "generation". chain (the second subscript) is called a "generation". The details
of application key derivation are described in the Section 11.1
application_secret section below.
|
V
HKDF-Expand-Label(., "app sender", [sender], Hash.length)
|
V
application_secret_[sender]_[0]
|
...
|
V
application_secret_[sender]_[N-1]
|
+--> HKDF-Expand-Label(.,"nonce", "", nonce_length)
| = write_nonce_[sender]_[N-1]
|
+--> HKDF-Expand-Label(.,"key", "", key_length)
| = write_key_[sender]_[N-1]
V
HKDF-Expand-Label(., "app sender", [sender], Hash.length)
|
V
application_secret_[sender]_[N]
As before the value [sender] represents the index of the member that
will use this key to send, encoded as a uint32.
[[ OPEN ISSUE: The HKDF context field is left empty for now. A
proper security study is needed to make sure that we do not need more
information in the context to achieve the security goals.]]
[[ OPEN ISSUE: At the moment there is no contributivity of
Application secrets chained from the initial one to the next
generation of Epoch secret. While this seems safe because
cryptographic operations using the application secrets can't affect
the group init_secret, it remains to be proven correct. ]]
The following rules apply to the usage of the secrets, keys, and
nonces derived above:
o Senders MUST only use a given secret once and monotonically
increment the generation of their secret. This is important to
provide Forward Secrecy at the level of Application messages. An
attacker getting hold of a member specific Application Secret at
generation [N+1] will not be able to derive the member's
Application Secret [N] nor the associated AEAD key and nonce.
o Receivers MUST delete an Application Secret once it has been used
to derive the corresponding AEAD key and nonce as well as the next
Application Secret. Receivers MAY keep the AEAD key and nonce
around for some reasonable period.
o Receivers MUST delete AEAD keys and nonces once they have been
used to successfully decrypt a message.
7. Initialization Keys 7. Initialization Keys
In order to facilitate asynchronous addition of clients to a group, In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish initialization keys that provide some it is possible to pre-publish initialization keys that provide some
public information about a user. ClientInitKey messages provide public information about a user. ClientInitKey messages provide
information about a client that any existing member can use to add information about a client that any existing member can use to add
this client to the group asynchronously. this client to the group asynchronously.
A ClientInitKey object specifies what ciphersuites a client supports, A ClientInitKey object specifies what ciphersuites a client supports,
skipping to change at page 31, line 8 skipping to change at page 30, line 8
* Epoch * Epoch
* Content Type * Content Type
* Nonce * Nonce
* Sender index * Sender index
* Key generation * Key generation
o Sign the protected content and metadata o Sign the plaintext metadata - the group ID, epoch, sender index,
and content type - as well as the message content
o Encrypt the sender information using the random nonce and the key o Randomly generate sender_data_nonce and encrypt the sender
derived from the sender_data_secret information using it and the key derived from the
sender_data_secret
o Encrypt the content using a content encryption key identified by o Encrypt the content using a content encryption key identified by
the metadata the metadata
The group identifier, epoch and content_type fields are copied from The group identifier, epoch and content_type fields are copied from
the MLSPlaintext object directly. The content encryption process the MLSPlaintext object directly. The content encryption process
populates the ciphertext field of the MLSCiphertext object. The populates the ciphertext field of the MLSCiphertext object. The
metadata encryption step populates the encrypted_sender_data field. metadata encryption step populates the encrypted_sender_data field.
Decryption follows the same step in reverse: Decrypt the metadata, Decryption follows the same step in reverse: Decrypt the metadata,
skipping to change at page 32, line 10 skipping to change at page 31, line 10
When parsing a SenderData struct as part of message decryption, the When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the sender field represents an occupied recipient MUST verify that the sender field represents an occupied
leaf in the ratchet tree. In particular, the sender index value MUST leaf in the ratchet tree. In particular, the sender index value MUST
be less than the number of leaves in the tree. be less than the number of leaves in the tree.
8.2. Content Signing and Encryption 8.2. Content Signing and Encryption
The signature field in an MLSPlaintext object is computed using the The signature field in an MLSPlaintext object is computed using the
signing private key corresponding to the credential at the leaf in signing private key corresponding to the credential at the leaf in
the tree indicated by the sender field. The signature covers the the tree indicated by the sender field. The signature covers the
metadata and message content, with the signature field truncated. plaintext metadata and message content, i.e., all fields of
MLSPlaintext except for the "signature" field.
The ciphertext field of the MLSCiphertext object is produced by The ciphertext field of the MLSCiphertext object is produced by
supplying the inputs described below to the AEAD function specified supplying the inputs described below to the AEAD function specified
by the ciphersuite in use. The plaintext input contains content and by the ciphersuite in use. The plaintext input contains content and
signature of the MLSPlaintext, plus optional padding. These values signature of the MLSPlaintext, plus optional padding. These values
are encoded in the following form: are encoded in the following form:
struct { struct {
opaque content[length_of_content]; opaque content[length_of_content];
uint8 signature[MLSCiphertextContent.sig_len]; uint8 signature[MLSCiphertextContent.sig_len];
skipping to change at page 34, line 15 skipping to change at page 33, line 18
3. Verify that the signature on the MLSPlaintext message verifies 3. Verify that the signature on the MLSPlaintext message verifies
using the public key from the credential stored at the leaf in using the public key from the credential stored at the leaf in
the tree indicated by the "sender" field. the tree indicated by the "sender" field.
4. Use the "operation" message to produce an updated, provisional 4. Use the "operation" message to produce an updated, provisional
GroupContext object incorporating the proposed changes. GroupContext object incorporating the proposed changes.
5. Use the "confirmation_key" for the new epoch to compute the 5. Use the "confirmation_key" for the new epoch to compute the
confirmation MAC for this message, as described below, and verify confirmation MAC for this message, as described below, and verify
that it is the same as the "confirmation" field in the that it is the same as the "confirmation" field in the
GroupOperation object. MLSPlaintext object.
6. If the the above checks are successful, consider the updated 6. If the the above checks are successful, consider the updated
GroupContext object as the current state of the group. GroupContext object as the current state of the group.
The confirmation value confirms that the members of the group have The confirmation value confirms that the members of the group have
arrived at the same state of the group: arrived at the same state of the group:
MLSPlaintext.confirmation = MLSPlaintext.confirmation =
HMAC(confirmation_key, GroupContext.transcript_hash) HMAC(confirmation_key, GroupContext.transcript_hash)
skipping to change at page 34, line 40 skipping to change at page 33, line 43
[[ OPEN ISSUE: It is not possible for the recipient of a handshake [[ OPEN ISSUE: It is not possible for the recipient of a handshake
message to verify that ratchet tree information in the message is message to verify that ratchet tree information in the message is
accurate, because each node can only compute the secret and private accurate, because each node can only compute the secret and private
key for nodes in its direct path. This creates the possibility that key for nodes in its direct path. This creates the possibility that
a malicious participant could cause a denial of service by sending a a malicious participant could cause a denial of service by sending a
handshake message with invalid values for public keys in the ratchet handshake message with invalid values for public keys in the ratchet
tree. ]] tree. ]]
9.1. Init 9.1. Init
[[ OPEN ISSUE: Direct initialization is currently undefined. A A group can always be created by initializing a one-member group and
client can create a group by initializing its own state to reflect a using adding members individually. For cases where the initial list
group including only itself, then adding the initial members. This of members is known, the Init message allows a group to be created
has computation and communication complexity O(N log N) instead of more efficiently.
the O(N) complexity of direct initialization. ]]
struct {
opaque group_id<0..255>;
ProtocolVersion version;
CipherSuite cipher_suite;
ClientInitKey members<0..2^32-1>;
DirectPath path;
} Init;
The creator of the group constructs an Init message as follows:
o Fetch a UserInitKey for each member (including the creator)
o Identify a protocol version and cipher suite that is supported by
all proposed members.
o Construct a ratchet tree with its leaves populated with the public
keys and credentials from the UserInitKeys of the members, and all
other nodes blank.
o Generate a fresh leaf key pair for the first leaf
o Compute its direct path in this ratchet tree
Each member of the newly-created group initializes its state from the
Init message as follows:
o Note the group ID, protocol version, and cipher suite in use
o Construct a ratchet tree as above
o Update the cached ratchet tree by replacing nodes in the direct
path from the first leaf using the direct path
o Update the cached ratchet tree by replacing nodes in the direct
path from the first leaf using the information contained in the
"path" attribute
The update secret for this interaction, used with an all-zero init
secret to generate the first epoch secret, is the "path_secret[i+1]"
derived from the "path_secret[i]" associated to the root node. The
members learn the relevant path secrets by decrypting one of the
encrypted path secrets in the DirectPath and working back to the root
(as in normal DirectPath processing).
[[ OPEN ISSUE: This approach leaks the initial contents of the tree
to the Delivery Service, unlike the sequential-Add case. ]]
[[ OPEN ISSUE: It might be desireable for the group creator to be
able to "pre-warm" the tree, by providing values for some nodes not
on its direct path. This would violate the tree invariant, so we
would need to figure out what mitigations would be necessary. ]]
9.2. Add 9.2. Add
In order to add a new member to the group, an existing member of the In order to add a new member to the group, an existing member of the
group must take two actions: group must take two actions:
1. Send a Welcome message to the new member 1. Send a Welcome message to the new member
2. Send an Add message to the group (including the new member) 2. Send an Add message to the group (including the new member)
The Welcome message contains the information that the new member The Welcome message contains the information that the new member
needs to initialize a GroupContext object that can be updated to the needs to initialize a GroupContext object that can be updated to the
current state using the Add message. This information is encrypted current state using the Add message. This information is encrypted
for the new member using HPKE. The recipient key pair for the HPKE for the new member using HPKE. The recipient key pair for the HPKE
encryption is the one included in the indicated ClientInitKey, encryption is the one included in the indicated ClientInitKey,
corresponding to the indicated ciphersuite. corresponding to the indicated ciphersuite. The "add_key_nonce"
field contains the key and nonce used to encrypt the corresponding
Add message; if it is not encrypted, then this field MUST be set to
the null optional value.
struct { struct {
HPKEPublicKey public_key; HPKEPublicKey public_key;
optional<Credential> credential; optional<Credential> credential;
} RatchetNode; } RatchetNode;
struct { struct {
opaque key<0..255>;
opaque nonce<0..255>;
} KeyAndNonce;
struct {
ProtocolVersion version; ProtocolVersion version;
opaque group_id<0..255>; opaque group_id<0..255>;
uint32 epoch; uint32 epoch;
optional<RatchetNode> tree<1..2^32-1>; optional<RatchetNode> tree<1..2^32-1>;
opaque transcript_hash<0..255>; opaque interim_transcript_hash<0..255>;
opaque init_secret<0..255>; opaque init_secret<0..255>;
optional<KeyAndNonce> add_key_nonce;
} WelcomeInfo; } WelcomeInfo;
struct { struct {
opaque client_init_key_id<0..255>; opaque client_init_key_id<0..255>;
CipherSuite cipher_suite; CipherSuite cipher_suite;
HPKECiphertext encrypted_welcome_info; HPKECiphertext encrypted_welcome_info;
} Welcome; } Welcome;
In the description of the tree as a list of nodes, the "credential" In the description of the tree as a list of nodes, the "credential"
field for a node MUST be populated if and only if that node is a leaf field for a node MUST be populated if and only if that node is a leaf
skipping to change at page 41, line 41 skipping to change at page 42, line 35
arrive at the following state: arrive at the following state:
KDF(KDF(Y)) KDF(KDF(Y))
/ \ / \
KDF(X) KDF(Y) KDF(X) KDF(Y)
/ \ / \ / \ / \
A X Y D A X Y D
11. Application Messages 11. Application Messages
The primary purpose of the handshake protocol is to provide an The primary purpose of the Handshake protocol is to provide an
authenticated group key exchange to clients. In order to protect authenticated group key exchange to clients. In order to protect
Application messages sent among those members of a group, the Application messages sent among the members of a group, the
Application secret provided by the handshake key schedule is used to Application secret provided by the Handshake key schedule is used to
derive encryption keys for the Message Protection Layer. derive nonces and encryption keys for the Message Protection Layer
according to the Application Key Schedule. That is, each epoch is
equipped with a fresh Application Key Schedule which consist of a
tree of Application Secrets as well as one symmetric ratchet per
group member.
Each client maintains their own local copy of the Application Key
Schedule for each epoch during which they are a group member. They
derive new keys, nonces and secrets as needed while deleting old ones
as soon as they have been used.
Application messages MUST be protected with the Authenticated- Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite. Note that "Authenticated" in this context with the MLS ciphersuite using the common framing mechanism. Note
does not mean messages are known to be sent by a specific client but that "Authenticated" in this context does not mean messages are known
only from a legitimate member of the group. To authenticate a to be sent by a specific client but only from a legitimate member of
message from a particular member, signatures are required. Handshake the group. To authenticate a message from a particular member,
messages MUST use asymmetric signatures to strongly authenticate the signatures are required. Handshake messages MUST use asymmetric
sender of a message. signatures to strongly authenticate the sender of a message.
Each member maintains their own chain of Application secrets, where 11.1. Tree of Application Secrets
the first one is derived based on a secret chained from the Epoch
secret. As shown in Section 6.6, the initial Application secret is
bound to the identity of each client to avoid collisions and allow
support for decryption of reordered messages.
Subsequent Application secrets MUST be rotated for each message sent The application key schedule begins with the application secrets
in order to provide stronger cryptographic security guarantees. The which are arranged in an "Application Secret Tree" or AS Tree for
Application Key Schedule use this rotation to generate fresh AEAD short; a left balanced binary tree with the same set of nodes and
encryption keys and nonces used to encrypt and decrypt future edges as the epoch's ratchet tree. Each leaf in the AS Tree is
Application messages. In all cases, a participant MUST NOT encrypt associated with the same group member as the corresponding leaf in
more than expected by the security bounds of the AEAD scheme used. the ratchet tree. Nodes are also assigned an index according to
their position in the array representation of the tree (described in
Appendix A). If N is a node index in the AS Tree then left(N) and
right(N) denote the children of N (if they exist).
Note that each change to the Group through a handshake message will Each node in the tree is assigned a secret. The root's secret is
cause a change of the group Secret. Hence this change MUST be simply the application_secret of that epoch. (See Section 6.6 for
applied before encrypting any new Application message. This is the definition of application_secret.)
required for confidentiality reasons in order for members to avoid
receiving messages from the group after leaving, being added to, or
excluded from the group.
11.1. Message Encryption and Decryption astree_node_[root]_secret = application_secret
The secret of any other node in the tree is derived from its parent's
secret using a call to Derive-App-Secret.
Derive-App-Secret(Secret, Label, Node, Generation, Length) =
HKDF-Expand-Label(Secret, Label, ApplicationContext, Length)
Where ApplicationContext is specified as:
struct {
uint32 node = Node;
uint32 generation = Generation;
} ApplicationContext
If N is a node index in the AS Tree then the secrets of the children
of N are defined to be:
astree_node_[N]_secret
|
|
+--> Derive-App-Secret(., "tree", left(N), 0, Hash.length)
| = astree_node_[left(N)]_secret
|
+--> Derive-App-Secret(., "tree", right(N), 0, Hash.length)
= astree_node_[right(N)]_secret
Note that fixing concrete values for GroupContext_[n] and
application_secret completely defines all secrets in the AS Tree.
11.2. Sender Ratchets
The secret of a leaf in the AS Tree is used to initiate a symmetric
hash ratchet which generates a sequence of keys and nonces. The
group member assigned to that leaf uses the j-th key/nonce pair in
the sequence to encrypt (using the AEAD) the j-th message they send
during that epoch. In particular, each key/nonce pair MUST NOT be
used to encrypt more than one message.
More precisely, the initial secret of the ratchet for the group
member assigned to the leaf with node index N is simply the secret of
that leaf.
application_[N]_[0]_secret = astree_node_[N]_secret
Keys, nonces and secrets of ratchets are derived using Derive-App-
Secret. The context in a given call consists of the index of the
sender's leaf in the ratchet tree and the current position in the
ratchet. In particular, the index of the sender's leaf in the
ratchet tree is the same as the index of the leaf in the AS Tree used
to initialize the sender's ratchet.
application_[N]_[j]_secret
|
+--> Derive-App-Secret(., "app-nonce", N, j, AEAD.nonce_length)
| = application_[N]_[j]_nonce
|
+--> Derive-App-Secret(., "app-key", N, j, AEAD.key_length)
| = application_[N]_[j]_key
|
V
Derive-App-Secret(., "app-secret", N, j, Hash.length)
= application_[N]_[j+1]_secret
Here, AEAD.nonce_length and AEAD.key_length denote the lengths in
bytes of the nonce and key for the AEAD scheme defined by the
ciphersuite.
11.3. Deletion Schedule
It is important to delete all security sensitive values S as soon as
they, or another value derived from them, is used for encryption or
decryption.
More precisely, the values application_[i]_[j]_key and
application_[i]_[j]_nonce are said to be "consumed" if they were used
either to:
o encrypt or (successfully) decrypt a message or
o if a key, nonce or secret derived from S has been consumed.
(This goes both for values derived via Derive-Secret and HKDF-Expand-
Label.)
Here, S may be the init_secret, update_secret, epoch_secret,
application_secret as well as any secret in the AS Tree or one of the
ratchets.
As soon as a group member consumes a value they MUST immediately
delete (all representations of) that value. This is crucial to
ensuring Forward Secrecy for past messages. Members MAY keep
unconsumed values around for some reasonable amount of time even if
their generating secret was already consumed (e.g. due to out of
order message delivery).
For example, suppose a group member encrypts or (successfully)
decrypts a message using the j-th key and nonce in the i-th ratchet.
Then, for that member, at least the following values have been
consumed and MUST be deleted:
o the init_secret, update_secret, epoch_secret, application_secret
of that epoch,
o all node secrets in the AS Tree on the path from the root to the
leaf with index i,
o the first j secrets in the i-th ratchet and
o application_[i]_[j]_key and application_[i]_[j]_nonce.
Concretely, suppose we have the following AS Tree and ratchet for
participant D:
G
/ \
/ \
E F
/ \ / \
A0 B0 C0 D0 -+- KD0
| |
| +- ND0
|
D1 -+- KD1
| |
| +- ND1
|
D2
Then if a client uses key KD1 and nonce ND1 during epoch n then it
must consume (at least) values G, F, D0, D1, KD1, ND1 as well as the
update_secret and init_secret used to derive G (i.e. the
application_secret). The client MAY retain (i.e., not consume) the
values KD0 and ND0 to allow for out-of-order delivery, and SHOULD
retain D2 to allow for processing future messages.
11.4. Further Restrictions
During each epoch senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used.
Note that each change to the Group through a Handshake message will
also set a new application_secret. Hence this change MUST be applied
before encrypting any new Application message. This is required both
to ensure that any users removed from the group can no longer receive
messages and to (potentially) recover confidentiality and
authenticity for future messages despite a past state compromise.
[[ OPEN ISSUE: At the moment there is no contributivity of
Application secrets chained from the initial one to the next
generation of Epoch secret. While this seems safe because
cryptographic operations using the application secrets can't affect
the group init_secret, it remains to be proven correct. ]]
11.5. Message Encryption and Decryption
The group members MUST use the AEAD algorithm associated with the The group members MUST use the AEAD algorithm associated with the
negotiated MLS ciphersuite to AEAD encrypt and decrypt their negotiated MLS ciphersuite to AEAD encrypt and decrypt their
Application messages according to the Message Framing section. Application messages according to the Message Framing section.
The group identifier and epoch allow a recipient to know which group The group identifier and epoch allow a recipient to know which group
secrets should be used and from which Epoch secret to start computing secrets should be used and from which Epoch secret to start computing
other secrets and keys. The "sender" identifier is used to derive other secrets and keys. The sender identifier is used to identify
the member's Application secret chain from the initial group the member's symmetric ratchet from the initial group Application
Application secret. The application generation field is used to secret. The application generation field is used to determine how
determine which Application secret should be used from the chain to far into the ratchet to iterate in order to reproduce the required
compute the correct AEAD keys before performing decryption. AEAD keys and nonce for performing decryption.
Application messages SHOULD be padded to provide some resistance Application messages SHOULD be padded to provide some resistance
against traffic analysis techniques over encrypted traffic. [CLINIC] against traffic analysis techniques over encrypted traffic. [CLINIC]
[HCJ16] While MLS might deliver the same payload less frequently [HCJ16] While MLS might deliver the same payload less frequently
across a lot of ciphertexts than traditional web servers, it might across a lot of ciphertexts than traditional web servers, it might
still provide the attacker enough information to mount an attack. If still provide the attacker enough information to mount an attack. If
Alice asks Bob: "When are we going to the movie ?" the answer Alice asks Bob: "When are we going to the movie ?" the answer
"Wednesday" might be leaked to an adversary by the ciphertext length. "Wednesday" might be leaked to an adversary by the ciphertext length.
An attacker expecting Alice to answer Bob with a day of the week An attacker expecting Alice to answer Bob with a day of the week
might find out the plaintext by correlation between the question and might find out the plaintext by correlation between the question and
skipping to change at page 43, line 34 skipping to change at page 48, line 5
required to achieve the security goals regarding cross-group attacks. required to achieve the security goals regarding cross-group attacks.
]] ]]
[[ OPEN ISSUE: Should the padding be required for handshake messages [[ OPEN ISSUE: Should the padding be required for handshake messages
? Can an adversary get more than the position of a participant in the ? Can an adversary get more than the position of a participant in the
tree without padding ? Should the base ciphertext block length be tree without padding ? Should the base ciphertext block length be
negotiated or is is reasonable to allow to leak a range for the negotiated or is is reasonable to allow to leak a range for the
length of the plaintext by allowing to send a variable number of length of the plaintext by allowing to send a variable number of
ciphertext blocks ? ]] ciphertext blocks ? ]]
11.2. Delayed and Reordered Application messages 11.6. Delayed and Reordered Application messages
Since each Application message contains the group identifier, the Since each Application message contains the group identifier, the
epoch and a message counter, a client can receive messages out of epoch and a message counter, a client can receive messages out of
order. If they are able to retrieve or recompute the correct AEAD order. If they are able to retrieve or recompute the correct AEAD
decryption key from currently stored cryptographic material clients decryption key from currently stored cryptographic material clients
can decrypt these messages. can decrypt these messages.
For usability, MLS clients might be required to keep the AEAD key and For usability, MLS clients might be required to keep the AEAD key and
nonce for a certain amount of time to retain the ability to decrypt nonce for a certain amount of time to retain the ability to decrypt
delayed or out of order messages, possibly still in transit while a delayed or out of order messages, possibly still in transit while a
skipping to change at page 45, line 27 skipping to change at page 49, line 42
Initialization keys are intended to be used only once and then Initialization keys are intended to be used only once and then
deleted. Reuse of init keys is not believed to be inherently deleted. Reuse of init keys is not believed to be inherently
insecure [dhreuse], although it can complicate protocol analyses. insecure [dhreuse], although it can complicate protocol analyses.
13. IANA Considerations 13. IANA Considerations
TODO: Registries for protocol parameters, e.g., ciphersuites TODO: Registries for protocol parameters, e.g., ciphersuites
14. Contributors 14. Contributors
o Benjamin Beurdouche o Joel Alwen
INRIA Wickr
benjamin.beurdouche@ens.fr joel.alwen@wickr.com
o Karthikeyan Bhargavan o Karthikeyan Bhargavan
INRIA INRIA
karthikeyan.bhargavan@inria.fr karthikeyan.bhargavan@inria.fr
o Cas Cremers o Cas Cremers
University of Oxford University of Oxford
cas.cremers@cs.ox.ac.uk cas.cremers@cs.ox.ac.uk
o Alan Duric o Alan Duric
skipping to change at page 46, line 6 skipping to change at page 50, line 22
singuva@twitter.com singuva@twitter.com
o Albert Kwon o Albert Kwon
MIT MIT
kwonal@mit.edu kwonal@mit.edu
o Eric Rescorla o Eric Rescorla
Mozilla Mozilla
ekr@rtfm.com ekr@rtfm.com
o Michael Rosenberg
Trail of Bits
michael.rosenberg@trailofbits.com
o Thyla van der Merwe o Thyla van der Merwe
Royal Holloway, University of London Royal Holloway, University of London
thyla.van.der@merwe.tech thyla.van.der@merwe.tech
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.barnes-cfrg-hpke] [I-D.irtf-cfrg-hpke]
Barnes, R. and K. Bhargavan, "Hybrid Public Key Barnes, R. and K. Bhargavan, "Hybrid Public Key
Encryption", draft-barnes-cfrg-hpke-01 (work in progress), Encryption", draft-irtf-cfrg-hpke-00 (work in progress),
March 2019. July 2019.
[IEEE1363] [IEEE1363]
"IEEE Standard Specifications for Password-Based Public- "IEEE Standard Specifications for Password-Based Public-
Key Cryptographic Techniques", IEEE standard, Key Cryptographic Techniques", IEEE standard,
DOI 10.1109/ieeestd.2009.4773330, n.d.. DOI 10.1109/ieeestd.2009.4773330, n.d..
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 46, line 43 skipping to change at page 51, line 19
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
skipping to change at page 47, line 46 skipping to change at page 52, line 21
[HCJ16] Husak, M., &#268;ermak, M., Jirsik, T., and P. [HCJ16] Husak, M., &#268;ermak, M., Jirsik, T., and P.
&#268;eleda, "HTTPS traffic analysis and client &#268;eleda, "HTTPS traffic analysis and client
identification using passive SSL/TLS fingerprinting", identification using passive SSL/TLS fingerprinting",
EURASIP Journal on Information Security Vol. 2016, EURASIP Journal on Information Security Vol. 2016,
DOI 10.1186/s13635-016-0030-7, February 2016. DOI 10.1186/s13635-016-0030-7, February 2016.
[I-D.ietf-trans-rfc6962-bis] [I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency Version 2.0", draft- Stradling, "Certificate Transparency Version 2.0", draft-
ietf-trans-rfc6962-bis-31 (work in progress), February ietf-trans-rfc6962-bis-32 (work in progress), June 2019.
2019.
[keyagreement] [keyagreement]
Barker, E., Chen, L., Roginsky, A., and M. Smid, Barker, E., Chen, L., Roginsky, A., and M. Smid,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", National Institute Using Discrete Logarithm Cryptography", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.sp.800-56ar2, May 2013. DOI 10.6028/nist.sp.800-56ar2, May 2013.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[signal] Perrin(ed), T. and M. Marlinspike, "The Double Ratchet [signal] Perrin(ed), T. and M. Marlinspike, "The Double Ratchet
Algorithm", n.d., Algorithm", n.d.,
<https://www.signal.org/docs/specifications/ <https://www.signal.org/docs/specifications/
doubleratchet/>. doubleratchet/>.
Appendix A. Tree Math Appendix A. Tree Math
One benefit of using left-balanced trees is that they admit a simple One benefit of using left-balanced trees is that they admit a simple
flat array representation. In this representation, leaf nodes are flat array representation. In this representation, leaf nodes are
even-numbered nodes, with the n-th leaf at 2*n. Intermediate nodes even-numbered nodes, with the n-th leaf at 2*n. Intermediate nodes
skipping to change at page 51, line 43 skipping to change at page 56, line 16
R = resolve(tree, right(x, n), n) R = resolve(tree, right(x, n), n)
return L + R return L + R
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Benjamin Beurdouche
Inria
Email: benjamin.beurdouche@inria.fr
Jon Millican Jon Millican
Facebook Facebook
Email: jmillican@fb.com Email: jmillican@fb.com
Emad Omara Emad Omara
Google Google
Email: emadomara@google.com Email: emadomara@google.com
Katriel Cohn-Gordon Katriel Cohn-Gordon
University of Oxford University of Oxford
Email: me@katriel.co.uk Email: me@katriel.co.uk
 End of changes. 53 change blocks. 
179 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/