[MLS] Fwd: Re: multiple devices per user?

Simon Friedberger <simon.tls@a-oben.org> Sun, 25 March 2018 10:54 UTC

Return-Path: <simon.tls@a-oben.org>
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 76C9A12785F for <mls@ietfa.amsl.com>; Sun, 25 Mar 2018 03:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wGRgGyVSh_jq for <mls@ietfa.amsl.com>; Sun, 25 Mar 2018 03:54:50 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org []) (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 61E8D127599 for <mls@ietf.org>; Sun, 25 Mar 2018 03:54:50 -0700 (PDT)
Received: from [] (helo=[]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <simon.tls@a-oben.org>) id 1f03IW-0003Ky-Cp for mls@ietf.org; Sun, 25 Mar 2018 12:54:48 +0200
References: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de>
To: mls@ietf.org
From: Simon Friedberger <simon.tls@a-oben.org>
X-Forwarded-Message-Id: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de>
Message-ID: <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org>
Date: Sun, 25 Mar 2018 12:54:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/YoV4B4QvyF7xsNJ0KLUdk0jWViA>
Subject: [MLS] Fwd: Re: multiple devices per user?
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
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, 25 Mar 2018 10:54:51 -0000

(Resent because I had the wrong sender address.)

Hi Jon!

On 25.03.2018 01:48, Jon Millican wrote:
> I think this is likely application-specific, but in our case we surface all device list changes within E2E threads, and you can look at the specific device public keys if wish. If you see that I have a new device, you can thus - in theory - ask me out of band whether the key is legitimate. The relevant part of our threat model here is "you should know what endpoints you're sending messages to before you send the message", so this fulfils that requirement.
I think having the partners deal with new devices is the wrong approach.
They probably don't know if a user has new devices so adding trust to
devices should be handled by the users with the devices.

> In our use case, this is common. Whenever somebody logs in on a new device, there's a strong chance that they don't have access to the previous one at the time - and won't want to be blocked from using Messenger until they can authorise the new device - particularly if it's a replacement phone for example. As Facebook Messenger itself is not an E2E app in the general case, we wouldn't want to add additional barriers that discourage people from using Secret Conversations.
I think the cases of replacing devices and adding them should be treated
differently. In the latter case trust has already been established and
can be transferred. In the first case, which is the case you are
concerned with, there is no trust and it should be an implementation
detail to highlight this to the user so the protocol should not make
them equivalent.

> I think I addressed this above, but we let people know when new devices are added to their account. Those who wish to can go check the list of devices on their account at this point.
But that only works with some form of key transparency, right? Otherwise
the device list can easily be manipulated.

Best Regards,