Re: [MLS] welcome_secret

Richard Barnes <rlb@ipv.sx> Tue, 04 August 2020 14:36 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DF03A0C0F for <mls@ietfa.amsl.com>; Tue, 4 Aug 2020 07:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_9zBchFHSTy for <mls@ietfa.amsl.com>; Tue, 4 Aug 2020 07:36:17 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71F23A0C08 for <mls@ietf.org>; Tue, 4 Aug 2020 07:36:15 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id t23so27897747qto.3 for <mls@ietf.org>; Tue, 04 Aug 2020 07:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; 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; d=1e100.net; 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: <ca00bc59-32e4-1ab6-8ac6-d5b4f285b013@aalto.fi> <22342_1596495550_5F2896BD_22342_209_1_CAL02cgSY3tGA+eQOspjr0v88UPCJke5hgmDg63p3Pn7deCCTsg@mail.gmail.com> <c711a614-4b08-365b-68f8-1b69a7b1ed58@aalto.fi>
In-Reply-To: <c711a614-4b08-365b-68f8-1b69a7b1ed58@aalto.fi>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 4 Aug 2020 10:36:01 -0400
Message-ID: <CAL02cgSx-46rPZ974BhMJ-N17=unPt6opcufo5Ci7mfe2e_Mdg@mail.gmail.com>
To: Chris Brzuska <chris.brzuska@aalto.fi>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000627ff005ac0e2da5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/FcKyDDhZr5sy-O1Iz3fvbu01LOs>
Subject: Re: [MLS] welcome_secret
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=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 <chris.brzuska@aalto.fi> 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 <chris.brzuska@aalto.fi>
> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing listMLS@ietf.orghttps://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>