Re: [MLS] multiple devices per user?

Simon Friedberger <simon.tls@a-oben.org> Sun, 25 March 2018 00:06 UTC

Return-Path: <simon.tls@a-oben.org>
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 7A2E7126BF3 for <mls@ietfa.amsl.com>; Sat, 24 Mar 2018 17:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OH6MspPqa5AY for <mls@ietfa.amsl.com>; Sat, 24 Mar 2018 17:06:54 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CFB12025C for <mls@ietf.org>; Sat, 24 Mar 2018 17:06:54 -0700 (PDT)
Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <simon.tls@a-oben.org>) id 1eztBQ-00045m-GG for mls@ietf.org; Sun, 25 Mar 2018 01:06:52 +0100
To: mls@ietf.org
References: <87efk9m7e9.fsf@fifthhorseman.net> <CABcZeBOAaA2_SRSimo2-x-jCw=YjvDsU7h0kPzU9WroTBBHoKA@mail.gmail.com> <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com>
From: Simon Friedberger <simon.tls@a-oben.org>
Message-ID: <b2ce2ddd-02e7-3161-dd97-fee31684366d@a-oben.org>
Date: Sun, 25 Mar 2018 01:06:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/b5K5Njuo5ZrnR0XOJb4AXLfFcqw>
Subject: Re: [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: Sun, 25 Mar 2018 00:06:56 -0000

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
> which users want to add a new device without an existing device being
> online, and these are incompatible with type #0 designs.

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


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

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