Re: [MLS] welcome_secret

[Richard Barnes <[e-mail]>]

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
>