[Sframe] MLS Integration Question

"Alwen, Joel" <alwenjo@amazon.com> Thu, 19 January 2023 16:25 UTC

Return-Path: <prvs=3769368e6=alwenjo@amazon.com>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE69C14CF1F for <sframe@ietfa.amsl.com>; Thu, 19 Jan 2023 08:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Z8gwLrS-FR for <sframe@ietfa.amsl.com>; Thu, 19 Jan 2023 08:25:13 -0800 (PST)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 757BEC151535 for <sframe@ietf.org>; Thu, 19 Jan 2023 08:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1674145514; x=1705681514; h=from:to:subject:date:message-id:mime-version; bh=LaO7w45+KMYNWk55zpCYqGBiDtxiB64Hz3Z/6hvQZTs=; b=f5MzIH9c1BiCGaxbniConz9ANObKoKJL/ZJxwvJ+WaENjBuJgWlzTvyo B/LBsEF3T5ymJoxfyv20MBB2AE3lLwNkPOF1zBm50FHFLUp+am+OQDdf/ vsxRlx9VzhPPld3cINBU3+EAA/0KDLRFjqEgGgAlx6eIp7CWay1YSrx/F M=;
X-IronPort-AV: E=Sophos;i="5.97,229,1669075200"; d="scan'208,217";a="290107861"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-iad-1a-m6i4x-47cc8a4c.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-6001.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2023 16:25:10 +0000
Received: from EX13D40EUA004.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1a-m6i4x-47cc8a4c.us-east-1.amazon.com (Postfix) with ESMTPS id A010B1616FC for <sframe@ietf.org>; Thu, 19 Jan 2023 16:25:08 +0000 (UTC)
Received: from EX19D048EUA001.ant.amazon.com (10.252.50.157) by EX13D40EUA004.ant.amazon.com (10.43.165.178) with Microsoft SMTP Server (TLS) id 15.0.1497.45; Thu, 19 Jan 2023 16:25:07 +0000
Received: from EX19D048EUA001.ant.amazon.com (10.252.50.157) by EX19D048EUA001.ant.amazon.com (10.252.50.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Thu, 19 Jan 2023 16:25:07 +0000
Received: from EX19D048EUA001.ant.amazon.com ([fe80::911d:ff7e:89cc:df88]) by EX19D048EUA001.ant.amazon.com ([fe80::911d:ff7e:89cc:df88%3]) with mapi id 15.02.1118.020; Thu, 19 Jan 2023 16:25:07 +0000
From: "Alwen, Joel" <alwenjo@amazon.com>
To: "sframe@ietf.org" <sframe@ietf.org>
Thread-Topic: MLS Integration Question
Thread-Index: AQHZLCCwvye029Nvlki1kRUVkOgzsQ==
Date: Thu, 19 Jan 2023 16:25:07 +0000
Message-ID: <de394d35aa2b4909876434abf42cde0f@amazon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.252.51.153]
Content-Type: multipart/alternative; boundary="_000_de394d35aa2b4909876434abf42cde0famazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/_5g1MO-FZWuvN97Ngagj1S0VMxc>
Subject: [Sframe] MLS Integration Question
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Media Frames <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2023 16:25:14 -0000

 _Hey everyone,


As Marta Mularczyk and I have been looking at using MLS to key SFrame we came across the following two questions/suggestions for the SFrame mailinglist.


1) Section 5.2 recommends how KIDs can be defined when using MLS as the key source. It domain separates between (epoch, leaf) pairs which is good. But by "only" domain separating on this it seems to imply that when encrypting frames from different streams (e.g. audio & video) from the same sender implementations need to coordinate the counter values in the SFrame header (lest the same IV is used more than once by the sender).  So, to make implementation easier / more flexible, we were thinking KID should also domain separate streams. E.g. the KID has an extra byte indicating the stream. That way encrypting different streams can be done independently and concurrently. Does that sound like a good idea to everyone? If so maybe we should update the SFrame MLS integration recommendation accordingly.

2) Another question about how KIDs are derived in section 5.2: to avoid reuse of the same key/nonce pairs in encryption due to "failure\crash -> resumption"  type scenarios maybe it would be a good idea to add a bit of entropy (say a byte) into KID that then goes in to the base_key generation. Basically, the suggestion is to have a similar mechanism to the nonce reuse guard in MLS (only this time its a key reuse guard).


3) Why recommend first generating sframe_epoch_secret as an Exporter and then doing HKDF-Expand again to generate individual base_keys? Is there an issue with just generating the base_keys directly as Exporter keys?


- Joël



Amazon Development Center Austria GmbH
Brueckenkopfgasse 1
8020 Graz
Oesterreich
Sitz in Graz
Firmenbuchnummer: FN 439453 f
Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz