diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index c779ef52..673caff4 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -135,6 +135,10 @@ shared keys with costs that scale as the log of the group size. RFC EDITOR PLEASE DELETE THIS SECTION. +draft-06 + +- Rename the GroupState structure to GroupContext (\*) + draft-05 - Common framing for handshake and application messages (\*) @@ -916,8 +920,8 @@ and only if the node is blank. ## Group State -Each member of the group maintains a representation of the -state of the group: +Each member of the group maintains a GroupContext object that +summarizes the state of the group: ~~~~~ struct { @@ -925,7 +929,7 @@ struct { uint32 epoch; opaque tree_hash<0..255>; opaque transcript_hash<0..255>; -} GroupState; +} GroupContext; ~~~~~ The fields in this state have the following semantics: @@ -942,7 +946,7 @@ The fields in this state have the following semantics: 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 message provides the information the new member needs to initialize -its GroupState. +its GroupContext. Different group operations will have different effects on the group state. These effects are described in their respective subsections @@ -1040,7 +1044,7 @@ following information to derive new epoch secrets: * The init secret from the previous epoch * The update secret for the current epoch -* The GroupState object for current epoch +* The GroupContext object for current epoch Given these inputs, the derivation of secrets for an epoch proceeds as shown in the following diagram: @@ -1051,20 +1055,20 @@ proceeds as shown in the following diagram: V update_secret -> HKDF-Extract = epoch_secret | - +--> Derive-Secret(., "sender data", GroupState_[n]) + +--> Derive-Secret(., "sender data", GroupContext_[n]) | = sender_data_secret | - +--> Derive-Secret(., "handshake", GroupState_[n]) + +--> Derive-Secret(., "handshake", GroupContext_[n]) | = handshake_secret | - +--> Derive-Secret(., "app", GroupState_[n]) + +--> Derive-Secret(., "app", GroupContext_[n]) | = application_secret | - +--> Derive-Secret(., "confirm", GroupState_[n]) + +--> Derive-Secret(., "confirm", GroupContext_[n]) | = confirmation_key | V - Derive-Secret(., "init", GroupState_[n]) + Derive-Secret(., "init", GroupContext_[n]) | V init_secret_[n] @@ -1414,14 +1418,14 @@ follows: described in {{message-framing}}. 2. Verify that the `epoch` field of enclosing MLSPlaintext message - is equal the `epoch` field of the current GroupState object. + is equal the `epoch` field of the current GroupContext object. 3. Verify that the signature on the MLSPlaintext message verifies using the public key from the credential stored at the leaf in the tree indicated by the `sender` field. 4. Use the `operation` message to produce an updated, provisional - GroupState object incorporating the proposed changes. + GroupContext object incorporating the proposed changes. 5. Use the `confirmation_key` for the new epoch to compute the confirmation MAC for this message, as described below, and verify @@ -1429,14 +1433,14 @@ follows: GroupOperation object. 6. If the the above checks are successful, consider the updated - GroupState 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 arrived at the same state of the group: ~~~~~ GroupOperation.confirmation = - HMAC(confirmation_key, GroupState.transcript\_hash) + HMAC(confirmation_key, GroupContext.transcript\_hash) ~~~~~ HMAC {{!RFC2104}} uses the Hash algorithm for the ciphersuite in @@ -1467,7 +1471,7 @@ group must take two actions: 2. Send an Add message to the group (including the new member) The Welcome message contains the information that the new member -needs to initialize a GroupState 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 for the new member using HPKE. The recipient key pair for the HPKE encryption is the one included in the indicated UserInitKey, @@ -1511,7 +1515,7 @@ are revealed to the new member. Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added. The sender of the Welcome message can -simply copy all fields from their GroupState object. +simply copy all fields from their GroupContext object. [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add. That is, the Welcome should be sent only if @@ -1519,7 +1523,7 @@ the Add succeeds, and is not in conflict with another, simultaneous Add. ]] An Add message provides existing group members with the information -they need to update their GroupState with information about the new +they need to update their GroupContext with information about the new member: ~~~~~ @@ -1548,7 +1552,7 @@ Add message. The client joining the group processes Welcome and Add messages together as follows: -* Prepare a new GroupState object based on the Welcome message +* Prepare a new GroupContext object based on the Welcome message * Process the Add message as an existing member would An existing member receiving a Add message first verifies @@ -1636,7 +1640,7 @@ state as follows: last node of the tree Note that, in step 4, there must be at least one non-null element in -the tree, since any valid GroupState must have the current member in +the tree, since any valid GroupContext must have the current member in the tree and self-removal is prohibited. The same reasoning justifies the existence of a non-blank leaf in the ratchet tree in step 5. @@ -1852,7 +1856,7 @@ this authentication scheme.]] [[ OPEN ISSUE: Currently, the group identifier, epoch and generation are contained as meta-data of the Signature. A different solution could be to -include the GroupState instead, if more information is required to achieve +include the GroupContext instead, if more information is required to achieve the security goals regarding cross-group attacks. ]] [[ OPEN ISSUE: Should the padding be required for handshake messages ?