Re: [MLS] welcome_secret

[Richard Barnes <[e-mail]>]

In the GroupSecrets struct...

struct {
  opaque joiner_secret<1..255>;
  optional<PathSecret> path_secret;
} GroupSecrets;


... the joiner_secret is the same for all joiners, but the path_secret is
potentially different for each joiner.


On Mon, Aug 3, 2020 at 7:36 PM Chris Brzuska <[e-mail]> wrote:

> Hi Richard,
>
> >>> I think you might be misunderstanding the encryption of the Welcome
> message a bit.  The GroupSecrets are encrypted with HPKE to the public keys
> of the new joiners; there's no shared key for the GroupSecrets.
>
> Thanks for helping to address my concerns - my understanding is that we
> use hybrid public-key encryption to encrypt the same symmetric-key to all
> new joiners and then use this (same) symmetric-key to encrypt the
> group_secrets, so we do not need to perform the encryption under the
> symmetric-key multiple times. I.e., the public-keys are different, but the
> symmetric-key is the same. Quote from the current document:
> "In order to allow the same Welcome message to be sent to all new members,
> information describing the group is encrypted with a symmetric key and
> nonce randomly chosen by the sender. This key and nonce are then encrypted
> to each new member using HPKE."
>
> This symmetric-key is just shared between the joiners, since it was given
> to all of them via HPKE key transport. Did I get this right, or are we
> using a different symmetric-key in each HPKE?
>
> ack re the rest for now, trying to resolve the clarification issue first.
>
> Chris
> On 04/08/2020 01:58, Richard Barnes wrote:
>
> Hi Chris,
>
> I think you might be misunderstanding the encryption of the Welcome
> message a bit.  The GroupSecrets are encrypted with HPKE to the public keys
> of the new joiners; there's no shared key for the GroupSecrets.
>
> Still, HPKE does make it possible to supply a PSK.  So you could provide
> the PSK ID on the outside of the Welcome, then use the (combined) PSK as a
> PSK for the GroupSecrets decryption *and* for the key schedule.  A few
> observations about that, though:
>
> 1. It would be marginally more efficient, since you're giving the same PSK
> IDs to everyone
> 2. It would leak to the DS the PSK IDs for the PSKs in use
> 3. If you have multiple PSKs, you would need to combine them *and* combine
> their IDs, since HPKE only has a single PSK input / PSK ID input
> 4. Would you want separate derived PSKs for HPKE and for the key schedule?
>
> On the other hand, if you don't use the PSKs with HPKE (just with the key
> schedule / GroupInfo decryption), then you do leak the member_secret and a
> path_secret to someone who has compromised an init_key, but if they don't
> know the PSK, they still can't join the group.
>
> For me, while including the PSK at the HPKE stage does seem like it would
> add some conceptual cleanness, the additional complexity seems a bit
> daunting, and I don't live the privacy leak.
>
> --Richard
>
>
> On Fri, Jul 31, 2020 at 3:22 AM Chris Brzuska <[e-mail]>
> wrote:
>
>> Hi all,
>>
>> I think that the current derivation of the welcome_secret (used to
>> encrypt the Group_Info) performs additional operations which are not
>> needed, and its use is not optimal from a security perspective (and not
>> necessary from an efficiency perspective). In the current version, we
>> encrypt the joiner_secret (without PSK) and then derive the
>> welcome_secret from the joiner-secret.
>>
>> Case 1: If the welcome_secret is not derived from the PSK, then one can
>> use the same symmetric-key for encrypting the Group_Info than for
>> encrypting the Group_Secrets. There is no efficiency loss, since for all
>> new members, the same symmetric key for encrypting the Group_Secrets is
>> used. In the case that the welcome_secret does not depend on the PSK, it
>> is not needed at all.
>>
>> Disadvantage of this: The PSK does not protect the GroupInfo, as
>> mentioned by Konrad.
>>
>> Additional Disadvantage of current version: Performs additional
>> unnecessary key derivations which do not add security/efficiency.
>>
>> Case 2: If we want to make the welcome_secret depend on the PSK, we do
>> not need to make it depend on the group_secrets. Making the
>> welcome_secret depend on the group_secrets does not add any security.
>> Instead, we only need to derive it from the PSK and the symmetric-key
>> which was sent to all group members. In this case, it makes sense that
>> both, the Group_Secrets and the Group_Info will be encrypted with the
>> same key rather than different keys. In this case, both the
>> Group_Secrets and the Group_Info will be protected by the combination of
>> PSK knowledge and knowing the secret-key for the PKE.
>>
>> Advantage of this: The PSK protects both the GroupInfo and the
>> GroupSecrets..
>>
>> Chris
>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing [e-mail]://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>