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

From: Simon Friedberger <[email-masked]>
Date: Sun, 25 Mar 2018 12:54:48 +0200

(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,
Simon

---

From: Jon Millican <[email-masked]>
Date: Sun, 25 Mar 2018 13:21:37 +0000

Hi Simon,

Thanks for the comments. I understand your point of view, and have at times advocated for many of the same suggestions. Hopefully the context below will help to clarify our design choices.

As I say, this is a specific use case in which we require devices to work immediately on log in. I absolutely accept that comparing long strings of random characters for all device changes is a difficult ask; but unfortunately in this specific case, requiring users to explicitly enrol a device from another wasn't feasible.

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.

Right: without transparency it's plausible that a service can present a split world view. This is why our threat model currently focuses on knowing where your messages are going. However viewing your own devices in this way allows you to at least see where your own messages are going (if foul play is happening on your own account, you need to know about the additional devices).

We've definitely had to make trade-offs in the design of this feature, but I'd be surprised to hear if any app hadn't had to make trade-offs. However, I'm certainly not advocating that MLS should be centred around our specific use case. I think that ours is one that's worth supporting; but that the use cases across the ecosystem of secure messaging apps are equally important to support.

Thanks,
Jon

On 25/03/2018, 11:55, "MLS on behalf of Simon Friedberger" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Jon!

    Best Regards,
    Simon
    
    _______________________________________________
    MLS mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=8JRh1KhcQfJkoXk7A_lTeGcdowgEi1M3B5NIbAHUZiY&s=b9hD5HuIChXtR8WJqJtQ2bUNn_eC2NlGc5pnUh4hz2A&e=

---

From: Simon Friedberger <[email-masked]>
Date: Sun, 25 Mar 2018 15:40:31 +0200

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.

> 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 rea…

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