[MLS] Key Schedule: New Document

Chris Brzuska <chris.brzuska@aalto.fi> Sun, 26 July 2020 20:02 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 077A63A140C for <mls@ietfa.amsl.com>; Sun, 26 Jul 2020 13:02:00 -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 OYg9dUvGsd1n for <mls@ietfa.amsl.com>; Sun, 26 Jul 2020 13:01:58 -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 2A8953A140A for <mls@ietf.org>; Sun, 26 Jul 2020 13:01:56 -0700 (PDT)
Received: from smtp-out-01.aalto.fi (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id 4FCA11157AE_F1DE130B for <mls@ietf.org>; Sun, 26 Jul 2020 20:01:52 +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 2807011579E_F1DE130F for <mls@ietf.org>; Sun, 26 Jul 2020 20:01:52 +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; Sun, 26 Jul 2020 23:01:51 +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; Sun, 26 Jul 2020 23:01:51 +0300
From: Chris Brzuska <chris.brzuska@aalto.fi>
To: Messaging Layer Security WG <mls@ietf.org>
Message-ID: <5f7e09a6-98d8-0584-249f-f9f268683484@aalto.fi>
Date: Sun, 26 Jul 2020 23:01:52 +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: exng6.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=LU0VYyNl1ogmNR013JvMs8OtjXRvz8VwaAlbRUoZ2C8=; b=SrKIOTQDSWSrKuLvDg0DuHXBSY7ISWQy0sNmcm4bTDRcm/i6KJ7hc39t+orUrUm+suPLQ8Jt2hDKWiCUA/LrsxzLe3TsWLrdB3GaN4aqiK0uQmT1akvAsh9KtByY3gMngb5Ku8wYcN3xfIoAswVDRIuE6Ci2DaKVMYPmT09b8NG+oUkoSpAB40Y29pLazoMmhArGCXjz1V4nQ+ix82wNzCYjri+AnAKhQduYUBc0lYa8Myb0r1TQubGQKEiO5syItI9Erahjgm2Ol4qskzy6HOrMddT3BzCNAds0wU55BvgypawfMfiZGM8wR/NknxQsipIoCuPUMMNGOWrUxc/ZhQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/IzktKGmKW06r8wNA5fwXueRIiXo>
Subject: [MLS] Key Schedule: New Document
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: Sun, 26 Jul 2020 20:02:00 -0000

Hi all,

I still need to process and understand the key schedule interface 
requirements which Richard discussed yesterday. In the meanwhile, I 
would like to make available an update on the original proposal (w.r.t. 
the original interface) and a discussion, available here in a (short) 
document (high-level discussion, no proofs):


Main points of the document:

- In the cfrg meeting, it was suggested to call HKDF.Extract on all 
three keys. Page 1 explains why relying on this "direct extract" 
construction implies the assumption that HKDF.Extract is an Triple-PRF 
(or n-PRF if there are more keys).

- Hugo Krawczyk brought the issue of low-entropy key material to my 
attention which I find an interesting topic for MLS: Sessions last very 
long and, after many updates, one would hope that entropy accumulates 
such that the keys become pseudorandom even if individual keys might 
have low entropy. For this purpose, it would be better to replace xor by 
HKDF.Extract which additively combines the entropy of its inputs (which 
xor does not necessarily do, see linked document above). This is the 
main reason why I favor to replace xor by HKDF.Extract. For a more 
nuanced discussion of pros and cons, see above document.