[MLS] multiple devices per user?

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 24 March 2018 22:33 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E81126DC2 for <mls@ietfa.amsl.com>; Sat, 24 Mar 2018 15:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srVJF-oxMXka for <mls@ietfa.amsl.com>; Sat, 24 Mar 2018 15:33:03 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8049212025C for <mls@ietf.org>; Sat, 24 Mar 2018 15:33:03 -0700 (PDT)
Received: from fifthhorseman.net (unknown [192.54.222.4]) by che.mayfirst.org (Postfix) with ESMTPSA id B7562F99A for <mls@ietf.org>; Sat, 24 Mar 2018 18:33:02 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id C5AE02066D; Sat, 24 Mar 2018 22:32:49 +0000 (GMT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: mls@ietf.org
Date: Sat, 24 Mar 2018 18:32:46 -0400
Message-ID: <87efk9m7e9.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/_RWLNYL4Uc1XEjo2b_HtestnwsU>
Subject: [MLS] 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: Sat, 24 Mar 2018 22:33:05 -0000

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