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

Simon Friedberger <> Sun, 25 March 2018 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE7AF1250B8 for <>; Sun, 25 Mar 2018 06:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d1HUU_CwnXAQ for <>; Sun, 25 Mar 2018 06:40:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 887A21205D3 for <>; Sun, 25 Mar 2018 06:40:33 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <>) id 1f05st-00041Q-P2 for; Sun, 25 Mar 2018 15:40:32 +0200
References: <> <> <>
From: Simon Friedberger <>
Message-ID: <>
Date: Sun, 25 Mar 2018 15:40:31 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [MLS] Fwd: Re: multiple devices per user?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Mar 2018 13:40:35 -0000

Hi Jon!

On 25.03.2018 15:21, Jon Millican wrote:
> As I say, this is a specific use case in which we require devices to work immediately on log in.
Yes, I totally agree that this should work. I would like to see a
solution with some kind of transition state where you can talk to a
device encrypted but it is clear that no authentication has been
performed yet. This can then be remedied by either comparing
fingerprints or scanning qr codes or authenticating from one of your
other devices.

>     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.
> This cuts to the reason why explicitly enrolling devices from trusted devices would be difficult for us. It's a common situation in which the original device is no longer available for whatever reason (lost, stolen, broken, sold, etc), so new devices that people log in to simply wouldn't be able to use Secret Conversations without choosing to explicitly enable the new device for it. Not only does this make things harder for people who explicitly plan to send an E2E message, but it means that people who don't know about the E2E mode will simply become inaccessible over time as they upgrade devices; and those people who do explicitly want to use Secret Conversations won't be able to reach their friends who are unaware of/uninterested in the feature. I'm not speaking in hypotheticals here; the original version of Secret Conversations worked in exactly this way: it was single-device per user, so if you replaced your phone, you would have to explicitly enable Secret Conversations on the new device, otherwise the enrolled device for your account would remain as the one that was enabled when we originally rolled out the feature. Over time, it was easily observable that people would become inaccessible via the feature, which ultimately was a barrier in the way of E2E communications, encouraging people to instead use normal Messenger conversations. Enabling multi-device, and the behaviour described above, fixed this issue, and you can now usually expect people on Messenger to be accessible via Secret Conversations.

Trying to pick this apart...
I agree with you that device loss has to be handled somehow and it would
be nice if it could be handled smoothly and in a way that can be used if
the device is just not available right now.

I don't quite understand the issue of people becoming unavailable. If
they have been so oblivious to encryption in the first place they
probably never performed any authentication and giving them a new key
doesn't actually make a difference. It seems like this problem is very
UI/UX related.

- Simon