Subject: Re: [MLS] welcome_secret

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Aug 2020 18:58:42 -0400

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 <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Chris Brzuska <[email-masked]>
Date: Tue, 4 Aug 2020 02:36:01 +0300

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
> 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
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     GroupSecrets..
>     [email-masked] <mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 4 Aug 2020 10:36:01 -0400

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 <[email-masked]> wrote:

> 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.
>
> 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
> 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?
>
> 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.
>
> MLS mailing [email-masked]://www.ietf.org/mailman/listinfo/mls
>