[MLS] welcome_secret

Chris Brzuska <chris.brzuska@aalto.fi> Fri, 31 July 2020 07:22 UTC

Return-Path: <chris.brzuska@aalto.fi>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 341D33A0EA7 for <mls@ietfa.amsl.com>; Fri, 31 Jul 2020 00:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=aalto.fi
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HG_uH3ePTeE9 for <mls@ietfa.amsl.com>; Fri, 31 Jul 2020 00:22:13 -0700 (PDT)
Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4AB3A0EF1 for <mls@ietf.org>; Fri, 31 Jul 2020 00:22:12 -0700 (PDT)
Received: from smtp-out-01.aalto.fi (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id 32429115638_F23C69DB for <mls@ietf.org>; Fri, 31 Jul 2020 07:22:05 +0000 (GMT)
Received: from exng2.org.aalto.fi (exng2.org.aalto.fi []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 0A8DF1155B6_F23C69DF for <mls@ietf.org>; Fri, 31 Jul 2020 07:22:05 +0000 (GMT)
Received: from exng6.org.aalto.fi ( by exng2.org.aalto.fi ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 10:22:04 +0300
Received: from [] ( by exng6.org.aalto.fi ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 10:22:04 +0300
From: Chris Brzuska <chris.brzuska@aalto.fi>
To: Messaging Layer Security WG <mls@ietf.org>
Message-ID: <ca00bc59-32e4-1ab6-8ac6-d5b4f285b013@aalto.fi>
Date: Fri, 31 Jul 2020 10:22:05 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-Originating-IP: []
X-ClientProxiedBy: exng1.org.aalto.fi ( To exng6.org.aalto.fi (
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=from:subject:to:message-id:date:mime-version:content-type:content-transfer-encoding; s=its18; bh=gnoQHfYLbAZljJ6iBiYstFlePaWmXRazVHd+abjAjXc=; b=C82kL1fnJL2VmkDOi4a4r1xeb4lbR9dmKeORbvHUTdvdbnyqnND7jqRs34GAyHChbXOwImnOPm1mni7jM5yCnQqgvbLBu6kuwwvEAGIVW4UU1r9JYcIE7Ahxukh3Q3iHHtwB4CMyB6daUyz8fmWXfJ2NgSGacjw2Vf0RLXG7BTMTfgSJRdaSrYqVlL8iJtOabc+d07kk2cF/zd5g81jGPe7zclg1mazOgy/2XIVynAM7fP+9SBleDQpkyQ0bcCfQGpFAPHUiLwdN5zZbVHKzye0872zTdU2DBdNHuK5LNdkAwSB78LlostlEEgXJWhbXG7HreyHmjHicdzqai61nDg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/oR6N6h0Rc-UUjmhk_i16KwywGvQ>
Subject: [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: Fri, 31 Jul 2020 07:22:15 -0000

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.