Re: [MLS] multiple devices per user?

Jon Millican <> Sat, 24 March 2018 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28BA812025C for <>; Sat, 24 Mar 2018 16:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=URtYwRL5; dkim=pass (1024-bit key) header.b=eWkdyaT/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fTTV1BgqcDul for <>; Sat, 24 Mar 2018 16:08:44 -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 C6DEC126DCA for <>; Sat, 24 Mar 2018 16:08:44 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w2ON8EmW003895; Sat, 24 Mar 2018 16:08:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=y4+UABTsyY6tSThQX+2Qa+99BGawdIIXBg65KPHKe58=; b=URtYwRL5+cCZBh4SSZdQtFrlbLaYp1VVFjSmXw+KWcwKZmxF+uL0+2zzgbm+j/9aQp9l oR6bHHiEPGZMwTlxi17ZlwmsYIym8NUNIGOvvWU9bCdzhip7Ni20+T/IAE9UNg0t2b86 EXcoNsGWs7C+7AOrjyQQDRXUSW5nKjFB9XU=
Received: from ([]) by with ESMTP id 2gwmh58wck-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2018 16:08:42 -0700
Received: from (2620:10d:c081:35::11) by (2620:10d:c081:35::12) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 16:08:41 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 16:08:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y4+UABTsyY6tSThQX+2Qa+99BGawdIIXBg65KPHKe58=; b=eWkdyaT/8bq0wEuUwQDpY/D3hrphXdpohYqB0UL1/oW0KFU0GEeKjpxG12uXRZYzCz32HTYi7j0YxskehfUqqdPlQ1+rPj8FiUxXWztWIt5lxKVjhT5w2Ef0NmRknAb2GBbsBFVrSGT/GsrjpHIpkWsw5fs1FU2Abv/QfpT7gh8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sat, 24 Mar 2018 23:08:39 +0000
Received: from ([fe80::c4ba:acd7:6982:b659]) by ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0609.012; Sat, 24 Mar 2018 23:08:39 +0000
From: Jon Millican <>
To: Eric Rescorla <>, Daniel Kahn Gillmor <>
CC: "" <>
Thread-Topic: [MLS] multiple devices per user?
Thread-Index: AQHTw8Ae2CgUeIFvK0mYODDXyt5r4qPf+1KAgAAHQoA=
Date: Sat, 24 Mar 2018 23:08:39 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR15MB1847; 7:77NSAK4NYYLjGvsbh+W3KX0v9UGb33RLaqd3o5yn2ACfAQpe7k39jig5U+CwA1ICm6UCBXUMaTOZ8l1op1V69M+KVA9rgBYe4kWCDsgohg7MaqubDME0B0sI94hw1l9w1WSjneJ5t0FD9muUcWu3MzFy0RRS0g/Isy9T95x9d+j4HRpjVF/3A/GA+VS8rsi67dzRBASxZ/SX8avSPqMv0PtgfajjUSwlEwLGGEb31u60tAU7UQnavonbwSLNCTMs; 20:zrAtde6TulGGmIzs9Soo+bVNl44ZFyKJUPDjdOlks94mZrqTqgddrViXahFQjNTntOel02HFT93PogU99GKf+r3cxniA28QcGGy/RYJtQJhfKC5BBE6j2sdtOXYUzyXfaAG9jrpJ2sT9txta1vUZL0ORxdAHnNE35qRppil/lkI=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 281ecc80-bb56-4ac2-8d69-08d591dc2e1f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1847;
x-ms-traffictypediagnostic: CY4PR15MB1847:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(209352067349851)(192374486261705)(81227570615382)(21748063052155)(211171220733660);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR15MB1847; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1847;
x-forefront-prvs: 0621E7E436
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(396003)(39380400002)(346002)(199004)(189003)(97736004)(6436002)(6486002)(8676002)(186003)(236005)(6512007)(6306002)(54896002)(81156014)(68736007)(53936002)(5250100002)(86362001)(6246003)(5890100001)(102836004)(55236004)(76176011)(53546011)(83716003)(59450400001)(316002)(478600001)(26005)(8936002)(81166006)(33656002)(229853002)(446003)(14454004)(4326008)(2900100001)(2906002)(3846002)(6116002)(99286004)(110136005)(6506007)(25786009)(36756003)(82746002)(5660300001)(105586002)(7736002)(66066001)(3280700002)(11346002)(106356001)(3660700001)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1847;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: rt7RSxcBLWB2dNEcRrHJ/YK2MV6DBpZl+0VUnh/Xz8NctGhFuq8ukXGIsnS8G+viNI5Alfaqlq1gGHUFuiWb+f58JrSJDkWQeY7P5ptUgesO7u/naFCOkvItIDK/CoiI3HFJK4zQYMCZuFwZGFJP7PimHH+sWtTYGdRBYSXeT+50K1Day8GsYTTz4gp0SoHeSS4k6iF6DdLu2zhjd2SWhnHy86IrVP8bOxbFgUxlmlp9COf9g11500i3ALT5kghAG6IVsfxrHb0YfiXfNBtkAgugbH0h3oMVTG/0VJrfa/bteaIogxY2le/TCXmeDHy4Tnx99xx/OySOJTLxIOCTFA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_02DC72FA0C574A1B920D4B456121CC55fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 281ecc80-bb56-4ac2-8d69-08d591dc2e1f
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2018 23:08:39.4820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1847
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-24_11:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <>
Subject: Re: [MLS] 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: Sat, 24 Mar 2018 23:08:47 -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.


On 24/03/2018, 22:43, "MLS on behalf of Eric Rescorla" <<> on behalf of<>> wrote:

On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor <<>> wrote:
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

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.

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

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.

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.

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

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.

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.

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