Re: [MLS] multiple devices per user?

Eric Rescorla <> Sat, 24 March 2018 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A533B126DC2 for <>; Sat, 24 Mar 2018 15:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qc1o5ohtZYGj for <>; Sat, 24 Mar 2018 15:43:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B53AC12025C for <>; Sat, 24 Mar 2018 15:43:20 -0700 (PDT)
Received: by with SMTP id c3-v6so13191552oib.5 for <>; Sat, 24 Mar 2018 15:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fzw7yuWOy6NqmOSfmafoQ/oHVvFimDfQuFVADtwPgUQ=; b=MkhrGrM3VF837R1p8Xdkurgn5z5ym9L58kC0Khq/V1VeFIEj7tNNl1MjkwBmnNSVbq OXZZJSOlKXu3JeYb/H3V+rIdXUhKE8wfXajWNeD794hNtRprlQR6AYyqOKTMAo16lEmZ FvsB8TA5En8NXnwBkdVbTAiQKnzpDA2FWQgcoBEFm+7u6VDQPx+1iY7N2iY7c9s8Adnw lEw3Ee8Q+j9LC0uDJgTnmNj1aqkft4z+tJzYp+VsLad/0vZZ/FfEVMlsG7GV+XROYXr9 dTj1Phb3zaQ7YgNBf2LKkx7gnW5Iz96DIQUs65hSLH0vrEahp6mMaLZAd3HgNqNdxJW3 83vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fzw7yuWOy6NqmOSfmafoQ/oHVvFimDfQuFVADtwPgUQ=; b=eibYGlMcPebdPAXF8L+0r55wLk7IeQvvmD1b92OTvZlm+LkIO25f2KqvHAUyPOIai9 XhJKmWBt0kmb1+qHOLGhXXN67MyaTJbtm6H21A3+mYhp6+hejuNItzF021ytYusn+E/L H1kcNamY+O4p0qwK5qo4Y+ClmG6RC3yrvefF7ck3CnmiPkvPcnfcsrOqmOmcUFW8QdAO jgAxZDevUI3pw6nWFL/kF6sOy/CMLgiIOX82yBt7i+GMTtYDBEiFkYJo3X2714AFjVfu b8+tbW6n3YWH2OxXzXd0qaGFa59AAJ67l4xPjiaIimVD3sr4WAPwC47jn3kdFIGAUAY8 znVQ==
X-Gm-Message-State: AElRT7GQS167gmcXra5rBIbLiw+ewtebcvKu8k0OIFFs0JThh27ymvB8 W+d9yOmoYnzOhf20eRh3y9seKRhnoeDS+xFDhyCLlw==
X-Google-Smtp-Source: AG47ELsl39m3TSOYPu/9mgfvlluvPbwt0iwGlFndwDSNoNSiedxsTA2xGfB9FzNhXyFWBJtRV3vOUADlof77xCQuYLU=
X-Received: by with SMTP id i72mr20127800oib.262.1521931399916; Sat, 24 Mar 2018 15:43:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 24 Mar 2018 15:42:39 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Sat, 24 Mar 2018 22:42:39 +0000
Message-ID: <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary="001a113ac71476feb60568304434"
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 22:43:23 -0000

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

Really? Because this kind of status reporting is actually a reasonably
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
> ction?

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