Subject: [MLS] multiple devices per user?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 24 Mar 2018 18:32:46 -0400

In the BoF at IETF 101, I expressed my concern about the way that
multiple devices fits in the architectural requirements.  I'm repeating
those concerns on-list here in the hopes of raising on-list discussion,
and trying to flesh them out here in more detail.

I see two use cases that might come under the "multi-device" rubric:

 a) device loss/recovery

 b) actual concurrent use (e.g. laptop + desktop + mobile)

i'll focus here mainly on (b), since i think (a) is a distinct
situation.

Privacy Considerations
----------------------

It's not clear to me that any user has a situation where they *want* to
indicate to other users of the group which device they're using.  I also
think that even in some situations where facts about device usage are
being published with some sort of opt-in consent, the privacy
implications are not well-understood by the users.
(e.g. https://www.cnet.com/news/trumps-tweets-android-for-nasty-iphone-for-nice/)

At any rate, a user who wants to let other participants know "i'm now at
home on the couch using my BananaTV" or even "this morning i'm using the
device that i usually only use in the evenings" can do so at the
application layer (i.e. in an explicit message to the other
participants).

The number of devices a user controls might itself be sensitive to the
user (e.g. a higher risk of device theft, or inference about the user's
behavior patterns)

Security Considerations
-----------------------

When the user has multiple devices, there are two possible approaches:

 0) sharing decryption-capable keys across devices (peers see a single
    key for each user)

 1) distinct per-device decryption-capable keys (peers see multiple keys
    per user)

One potential argument is that option (1) might provide
"transparency" -- or visibility of a key change in the event of an
adversary who tries to change the keys of a client.  but i don't think
this argument works.

At the BoF it was clear that even if the design assumes (1), it's
possible for systems to implement (0) if they want to hide the number of
devices (or if they're adversarial and have compromised an endpoint).
So there isn't a clear security-through-transparency argument.

Furthermore, it's not clear what a group conversation participant can
*do*, security-wise, in the event of recieving such a message from
another participant -- is this actually a new phone, or is it a wiretap
injection?  should i ask the user about it?  should i take action?  what
ction?

To avoid UX warning fatigue, i'm wary about introducing more of these
events than are strictly necessary (scenario (a) above probably
represents a "necessary" event, sadly, but "i just got a new phone"
doesn't seem necessary).

And finally, we presumably want any sort of device change to be
authorized from an already-known device for the same user.  So when the
user gains an additional device, we need *some* form of communication
between the new device and an old device.  That interaction could be a
confirmation-signature action (case 1), or it could be a
private-key-sharing interaction (case 0).

Single-key-per-participant seems better
---------------------------------------

So exposing the presence of multiple devices to the other participants
seems strictly worse from a privacy perspective, and it may facilitate
unnoticed wiretap-style extra-key-injection (due to concerns about
warning fatigue).

Wouldn't it be safer and simpler to assume a design that insists on
single-key-per-user, and hide multi-device private-key-synchronization
from the other participants in the group chat?

i wouldn't object to specifying a mechanism for private-key
synchronization between devices held by the same user; but i worry about
exposing multiple-keys-per-user to the messaging group itself.  it may
make the protocol worse in terms of privacy, usability, and security.

     --dkg

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Mar 2018 22:42:39 +0000

On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor <[email-masked]
> wrote:

> indicate to other users of the group which device they're using.

Really? Because this kind of status reporting is actually a reasonably
common
feature of IM systems.

Security Considerations

The reason for #1 isn't transparency, it's that there are use cases in
which users want to add a new device without an existing device being
online, and these are incompatible with type #0 designs.

> injection?  should i ask the user about it?  should i take action?  what

Generally, I wouldn't expect them to take any action at all. It's a user's
responsibility to ensure that the right number of devices are registered
to their account, just as its common for the number of Web browsers
one has attached to ones Gmail account.

> authorized from an already-known device for the same user.

This was not in fact my assumption, for the reason indicated above

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Sat, 24 Mar 2018 22:52:48 +0000

On Sat, Mar 24, 2018 at 3:43 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor <
> [email-masked]> wrote:
>

Also, allowing exfiltration of keys in order to allow cross-device sharing
seems to introduce its own set of problems.

>> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Jon Millican <[email-masked]>
Date: Sat, 24 Mar 2018 23:08:39 +0000

I’d like to second Ekr’s points here. To provide a concrete use case, in Facebook Messenger, we want Secret Conversations to work for a user as soon as they log in on a new device. This somewhat blurs the boundary between device loss/recovery and concurrent use as it is used for both situations; but we don’t want to require existing device to authorise new devices as – to be perfectly frank – we’re not convinced that most people would actually do this, and it puts a potential usability barrier in the way of people using the E2E mode. While Wire is fully E2E, I believe that they similarly allow logging into a new device without any interaction with old devices. As far as I’m aware, neither service synchronises decryption keys between devices, and we instead just treat each new device as effectively a new group participant.

However there is a third option that we alluded to in the ART paper, that sits somewhere between your options 0 and 1.

2) Give each user as a separate ART subtree. The leaves of the group thread tree would then simply be the roots of each user’s subtree. You can then use this to mask the number of devices each user has, but without synchronising their private key material. The same algorithms would apply to the subtrees, so we’d get FS and PCS with respect to each device – including when they’re added and removed.

This option could be quite flexible, so you could then make a number of the design choices discussed application-specific. E.g. if you want to require new devices on an account to be enrolled by others, then you can do this without surfacing any warnings. Otherwise you could choose to notify that the user’s leaf changed: or even the full list of each user’s devices if you wished.

Jon

On 24/03/2018, 22:43, "MLS on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor <[email-masked]<mailto:[email-masked]>> wrote:

 a) device loss/recovery

Privacy Considerations
----------------------

Really? Because this kind of status reporting is actually a reasonably common
feature of IM systems.

Security Considerations
-----------------------

-Ekr

---

From: Jon Millican <[email-masked]>
Date: Sat, 24 Mar 2018 23:40:32 +0000

I should mention that this third option – at least in the context of MLS – is currently something of a half-baked idea. It’s an approach that should work in a hypothetical ART-based protocol, but we haven’t dug into it enough to figure out whether it will fit into the proposed constraints for MLS.

On 24/03/2018, 23:08, "Jon Millican" <[email-masked]<mailto:[email-masked]>> wrote:

Jon

 a) device loss/recovery

Privacy Considerations
----------------------

Security Considerations
-----------------------

-Ekr

---

From: Simon Friedberger <[email-masked]>
Date: Sun, 25 Mar 2018 01:06:47 +0100

Hi Jon and Eric!

On 25.03.2018 00:08, Jon Millican wrote:
>
> I’d like to second Ekr’s points here. To provide a concrete use case,
> in Facebook Messenger, we want Secret Conversations to work for a user
> as soon as they log in on a new device. This somewhat blurs the
> boundary between device loss/recovery and concurrent use as it is used
> for both situations; but we don’t want to require existing device to
> authorise new devices as – to be perfectly frank – we’re not convinced
> that most people would actually do this, and it puts a potential
> usability barrier in the way of people using the E2E mode.
>

Won't this give us e2e encryption but no e2e security against active
attackers? If we remove authentication in favor of ux what's to stop an
mitm attacker?

Eric:
> it's that there are use cases in

I'm not sure that devices being added is such a common occurence that it
would prohibit asking for authorization from a different device.

> one has attached to ones Gmail account.

How would a user find out which devices are registered to their account
when they don't have to authorize them? And if it can be done, isn't
"authorize-on-first-use" more user-friendly than expecting that users
will maintain a list of authorized devices, i.e. check at random
intervals if the list is still correct?

Best Regards,
Simon

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Mar 2018 00:27:08 +0000

> attackers? If we remove authentication in favor of ux what's to stop an

Just for clarity, I assume you mean a MITM attacker who controls the
authentication server, right

> would prohibit asking for authorization from a different device.

OK. I guess Jon and others who run IM services can weigh in here on their
experience, but
I can tell you about Mozilla's experience in a not-dissimilar setting,
namely browser sync.
Firefox used to have a system which required interaction between the
original device
and the one to be enrolled, and we found it to be a very aversive user
experience which
we eventually abandoned in favor of a more conventional password based
design.

Eric:
> when they don't have to authorize them?

I've been assuming that systems that wanted to offer strong guarantees some
form of key transparency so that users could determine which other devices
were registered to their account.

> And if it can be done, isn't
> will maintain a list of authorized devices,

No, I don't believe so.

> i.e. check at random

I'm not a UX designer, but this isn't the UX I had in mind. Rather, I was
expecting
that the app would notify you when a new device was registered. This is
already
the UX that many Web sites provide for situations when you log in on a new
browser (though that's for cases when the threat is password compromise
which
is why it's safe to offer via the browser or email, rather than in the app).

-Ekr

-Ekr

---

From: Jon Millican <[email-masked]>
Date: Sun, 25 Mar 2018 00:48:41 +0000

Hi Simon!

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.

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 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.

Hope that all makes sense,
Jon

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

    Hi Jon and Eric!

    

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 25 Mar 2018 14:28:40 +0100

Hiya,

> from the other participants in the group chat?

Speaking as a user and teeny-weeny service operator (most
recently of the riot/matrix variety), but not as an implementer:-

- I've no problem with device specifics being visible to the
small groups of which I'm a member or that I support.

- I would prefer that device specific details not be visible
in larger settings, e.g. were I a member of a group with ~100
members or more say, or if using some federation scheme, where
I won't necessarily know group sizes or memberships.

- I understand that it might be simpler to treat each device
independently within MLS, but would be happier if the WG spent
a bit of time considering whether it is possible to do better
and provide a way for applications to hide device specifics if
that makes sense to the application.

Cheers,
S.

---

From: Rich Persaud <[email-masked]>
Date: Mon, 26 Mar 2018 05:16:30 -0400

On Mar 24, 2018, at 18:42, Eric Rescorla <[email-masked]> wrote:
>> On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
>> 

In Wire, if Alice has marked each of Bob's device fingerprints as "verified", then the addition of a new device by Bob results in an immediate message to Alice.  The recommended action is to verify the new fingerprint out of band, then Alice can mark Bob's new device as "verified". 

> one has attached to ones Gmail account.

Here is a scenario on iOS:

(1) User is logged into Facebook via Chrome.  User is not logged into Facebook in Safari, to avoid Facebook tracking on non-Facebook websites visited in Safari.

(2) User receives FB email notification in Apple email.  If user clicks on a link in the email, it opens in Safari and Facebook *automatically logs the user in without a password*.

(3) User then receives FB email notification that they have added a new device.

(4) User must now manually log out of Facebook, then click on a tiny close button on account icon to delete the cookie associated with that user, to avoid Facebook tracking on non-Facebook websites.  That removes (?) the browser as a known device.

Each of the individual UX decisions above could make sense in some contexts, but when combined on iOS where the user cannot choose the browser in which email links are opened, it leads to an undesirable UX where the user must invest repeated effort to ensure that the right number of devices are registered to their account.

Rich

---

From: Richard Barnes <[email-masked]>
Date: Mon, 26 Mar 2018 22:45:51 +0100

Hey all,

Sorry, I was in meetings over the weekend and missed the fun :)  Let me try
to sum up.

tl;dr:  It's an application decision. The protocol should be oriented
around per-device keys, but we should also document the privacy concerns
and some approaches to mitigating them.

I agree with DKG that we should not hard-code a one-key-per-device
assumption into the protocol.  But at the same time, I don't want this
group to have to assume the complexity of a protocol to sync keys across
devices in addition to what it's already got.  And has been pointed out,
there are some valid reason to want individual device keys to be exposed in
the protocol, e.g., key comparison and device revocation.

Fortunately, we don't have to make a choice here.  Because the protocol
doesn't know whether a leaf key is an actual leaf or the root of a subtree,
there's a clean interface point where applications can make a decision.
You could even imagine different clients in one group making different
decisions.

So I would suggest we do the following:
- No change to the protocol document
- In the architecture document:
  - Lay out the privacy risk that can arise from using per-device keys
  - Present the two approaches discussed in this thread for how to do key
sync (explicit sync and sub-trees)

That way, the WG's document set will provide guidance to implementors about
the risks and how to mitigate, without diving into the complexity of a full
protocol.

--Richard

On Mon, Mar 26, 2018 at 10:16 AM, Rich Persaud <[email-masked]> wrote:

> In Wire, if Alice has marked each of Bob's device fingerprints as
> "verified", then the addition of a new device by Bob results in an
> immediate message to Alice.  The recommended action is to verify the new
> fingerprint out of band, then Alice can mark Bob's new device as
> "verified".
>
>
> (1) User is logged into Facebook via Chrome.  User is not logged into
> Facebook in Safari, to avoid Facebook tracking on non-Facebook websites
> visited in Safari.
>
> (2) User receives FB email notification in Apple email.  If user clicks on
> a link in the email, it opens in Safari and Facebook *automatically logs
> the user in without a password*.
>
> (4) User must now manually log out of Facebook, then click on a tiny close
> button on account icon to delete the cookie associated with that user, to
> avoid Facebook tracking on non-Facebook websites.  That removes (?) the
> browser as a known device.
>
> Each of the individual UX decisions above could make sense in some
> contexts, but when combined on iOS where the user cannot choose the browser
> in which email links are opened, it leads to an undesirable UX where the
> user must invest repeated effort to ensure that the right number of devices
> are registered to their account.
>
> Rich
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 27 Mar 2018 16:56:57 -0400

> seems to introduce its own set of problems.

it's not clear that any protocol can prevent key exfiltration from an
endpoint that wants to exfiltrate keys outside of that protocol.  so i
don't think it's a question of "allowing" here.

         --dkg

---

From: Justin Uberti <[email-masked]>
Date: Tue, 27 Mar 2018 23:40:58 +0000

> don't think it's a question of "allowing" here.

There are hardware architectures (e.g. Secure Enclave) where key material
can be used for encryption but the raw private key cannot be extracted. If
the protocol requires access to the key in order to enroll a new device,
this reduces the efficacy of the hardware mechanism (or may not work at
all).

Overall, I agree with Richard on this - it's an application decision. There
are some niceties associated with a single key per user, but this will not
be an option in all circumstances.