Re: [MLS] Why give the root a pk/sk?

Joel Alwen <jalwen@wickr.com> Tue, 12 May 2020 04:18 UTC

Return-Path: <jalwen@wickr.com>
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 385C03A0B32 for <mls@ietfa.amsl.com>; Mon, 11 May 2020 21:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.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 tqZuVrtu7f-b for <mls@ietfa.amsl.com>; Mon, 11 May 2020 21:18:17 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 2BD923A0B5B for <mls@ietf.org>; Mon, 11 May 2020 21:18:17 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id w65so5733975pfc.12 for <mls@ietf.org>; Mon, 11 May 2020 21:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wPNz/6xfhN+dGT94rhSzsIepyBtUDHutAvrL03QZlok=; b=KhCdNInwwBdqvOt2ltJYgFdvGv6rNR4AENbCu7ygUNdepfdo3q/gOm65UbV5ezgTLO e+z8sx8H0xGc+6F3MIgfop0BsTbjzCbTMKDRJARnS3NWj9rmUCGe6xuFTw7Ja+JCAWpI o/LRUh5StRv2xH5T097isTNIS0/4VkDZ7NAHuJMtzspmOaOCHdgZ1xs7bP3f16nfQRby hoAkcv8FaRRyvtIlgATCCd7bfvAz2GEXJCMN1oLo7afecv7TbktTJGdyq51VbKHGt9PE EFoKhDC8Cntf9c1i6t/HcBtHLghhCKlJjpTfcMgb9VYLhcN+0+YjHnBIm/+XXy3CqPzY miPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=wPNz/6xfhN+dGT94rhSzsIepyBtUDHutAvrL03QZlok=; b=EVfdn2kk079UWTPjksRqA+H2UZ2OhAsOBFURmt/qCH0UeSKvH8DYIVh8ynFIIMEfYw Tsf5s+CwpsIK4y3BsreOJ0kpisFJ4dQd37uJGNa0rychtm009X/ClnOWo7onGtwr09oh BvkAa/EU34AF5PokWGdHky7YYa8t5MHzbCJd/g1HefVkfGtk0cJXn1NAkGFcXO0ZsbG7 7mmKPSXztAKXQ3YFQJm9Jrdl++UlCMB7FmqDQ6xZZVptNyuRx2HMJ3cHUDFCvCwCbbwL oqMsyiAqARKjHzUt8ixil3rGFBCpKDG3afdNrB6wjz/l06zgeyVDBntj1uSpIEaGmy8d /bjw==
X-Gm-Message-State: AGi0PuaKTYZ6/1bf91FCnPoi1ouBsEbtC6QTjrV9jypSsQjGWp3ddB6a Kla7ZnPWdEoAyboSXqTSTIhD880ihYI=
X-Google-Smtp-Source: APiQypKrbjVNSrBQOdjt/3UaJNp1qOnxNni4Xuqea1rieObeScvfi42UnBE00auqxR4nwAQdIo5GRw==
X-Received: by 2002:a63:1f62:: with SMTP id q34mr17476459pgm.197.1589257096224; Mon, 11 May 2020 21:18:16 -0700 (PDT)
Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id o6sm10561095pfp.172.2020.05.11.21.18.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 21:18:15 -0700 (PDT)
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, Raphael Robert <raphael=40wire.com@dmarc.ietf.org>
Cc: Richard Barnes <rlb@ipv.sx>, Messaging Layer Security WG <mls@ietf.org>
References: <B92CE6CF-409A-49A9-95E5-FC680E17BF67@wire.com> <F106E964-D4FF-40EC-A595-1616D270F774@inria.fr>
From: Joel Alwen <jalwen@wickr.com>
Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw==
Message-ID: <31cfedfc-2c9e-bb6b-7b6b-22c081cc9404@wickr.com>
Date: Tue, 12 May 2020 13:18:13 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <F106E964-D4FF-40EC-A595-1616D270F774@inria.fr>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/3gERkPMYMtKIQirKcclXvw7b79w>
Subject: Re: [MLS] Why give the root a pk/sk?
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, 12 May 2020 04:18:19 -0000

Thanks for the answers everyone!

> Send-from-outside should be derived from the key schedule.

Yup, totally. Way better (global) forward secrecy that way.

So to summarize, what I'm reading out of these answers is that MLS doesnt really
have a need for the root's PK/SK and extra Derive/HKDF calls.

- Joël

On 12/05/2020 12:42, Benjamin Beurdouche wrote:
> @Joel This is because this is part of TreeKEM which has no key schedule and is
> not specific to MLS.
> B.
> 
>> On May 11, 2020, at 11:21 PM, Raphael Robert
>> <raphael=40wire.com@dmarc.ietf.org> wrote:
>>
>> I agree with that. Send-from-outside should be derived from the key schedule.
>>
>> Raphael
>>
>>> On 11 May 2020, at 22:22, Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>> wrote:
>>>
>>> I don't think it's necessary.  IIRC, the Go library doesn't do this, and it
>>> seems to implement the remainder of the spec just fine.
>>>
>>> The only case where it might be useful is if we implemented a
>>> send-to-group-from-outside functionality, in support of Add initiated by the
>>> new joiner.  But even in that case, it would probably be better to derive a
>>> key pair off of the key schedule.
>>>
>>> --RLB
>>>
>>> On Mon, May 11, 2020 at 4:26 AM Joel Alwen <jalwen@wickr.com
>>> <mailto:jalwen@wickr.com>> wrote:
>>>
>>>     Quick question for the list. Why assign a pk/sk to the root of the
>>>     ratchet tree?
>>>     (E.g. on Page 18 in the toy example root node G gets node_priv[1] and
>>>     node_pub[1].)
>>>
>>>     The commit_secret is then derived HKDF-Expand-Label again on the
>>>     path_secret for
>>>     the root.
>>>
>>>     Isn't it true that the only thing we ever encrypt to a node's pk is its
>>>     parent's
>>>     path_secret? If so I'm not seeing the point of the pk/sk at the root and the
>>>     extra call HKDF-Expand to get commit_secret. Am I missing something?
>>>
>>>     - Joël
>>>
>>>     _______________________________________________
>>>     MLS mailing list
>>>     MLS@ietf.org <mailto:MLS@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/mls
>>>
>>> _______________________________________________
>>> MLS mailing list
>>> MLS@ietf.org <mailto:MLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls