[MLS] multiple devices per user?

[Daniel Kahn Gillmor <[e-mail]>]

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