Re: [MLS] welcome_secret

Richard Barnes <> Tue, 04 August 2020 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9DF03A0C0F for <>; Tue, 4 Aug 2020 07:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S_9zBchFHSTy for <>; Tue, 4 Aug 2020 07:36:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C71F23A0C08 for <>; Tue, 4 Aug 2020 07:36:15 -0700 (PDT)
Received: by with SMTP id t23so27897747qto.3 for <>; Tue, 04 Aug 2020 07:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uzjutMb8ebVc4eN/LNLfUKF0PuvMsKU0A0aNPb+w2i0=; b=wJeabpVvKmtU5Do5JBn06OeFBTQ5olKTWJbjt/i62BIB5JYl7qRCd3DLwlJOG/mya+ lGRYEW0vTBd7H2GH4p6XNT3qF41dMN3ZViEXPm1HmTVggx68hqTLLQ3ixf7xaKX3D6VH b8qUqkmjkHXwBiRyYo7TTSBLZGuVlb4nuafBjFX/EL+TkP8l8D4WaThG2tvPv6K1DXEZ N/vD2qdLV+ZUlcGWBk0FBW3cHQdRioZBJ46ahsqxtvUI48DYgkV45HTjv0PnB/gIlHb0 uyAKFrcV8sCPaytrKr3voM/gGrYmK4ld9MgO57aAhGWoWjNifZcpX0VgJQMSlo5nlKZ2 BOxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uzjutMb8ebVc4eN/LNLfUKF0PuvMsKU0A0aNPb+w2i0=; b=GqFX5EqQCU6Bhnnhqs9e/RgBCBCkgMiMMVZt0IQN8W6lGeODbeUTI5Aa4VbdMPGY/h 6cjHgo09tA3Vxj/dCus++Q0iiGX7uYEgbt5Vm1VfCOCajUYKqaoWo9ihsZXTU5L6+vV/ blFAjVpCaEnDqwnMzDh7gt1uSTDK9VYFjkH9hGI1PCwVASAgsq1ZVYGSJ1zDCYHTfYn1 Pyft4DjSk3q31Ccwu0i8UmmirEBLmEluMOIQDQdTIIB+Blo39W/5kCYTQfgHMzyQTbG0 8LTiGE9H9uK2Flh+lY/949xKEqJX9+e3Es5qdUgM7Qay7cKx+OmLd6qz3MKwwrNV7KMa CC5Q==
X-Gm-Message-State: AOAM533ESlELlR4wLtSsdYxs4ukucZIaa5ZKcFN6IfW0eKQ7d6yZ/h8P Zqzgtq77tVjAluJ2N+1/WNeuNlcBpMojw00PiaNVQg==
X-Google-Smtp-Source: ABdhPJzSt9pw0J88JcDbBajjy7T+fu4Va8P4L9olaDQa4MVwuC+XpuKSylZqpIzgJw2doOgMbhKsWR8gfCXIGkJqoiU=
X-Received: by 2002:aed:34e2:: with SMTP id x89mr21624168qtd.313.1596551774494; Tue, 04 Aug 2020 07:36:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Tue, 4 Aug 2020 10:36:01 -0400
Message-ID: <>
To: Chris Brzuska <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000627ff005ac0e2da5"
Archived-At: <>
Subject: Re: [MLS] welcome_secret
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Aug 2020 14:36:19 -0000

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 <> 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 <>
> 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
> _______________________________________________
> MLS mailing listMLS@ietf.org
> _______________________________________________
> MLS mailing list