[MLS] Fwd: Re: multiple devices per user?

Simon Friedberger <simon.tls@a-oben.org> Sun, 25 March 2018 10:53 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 51A25127867 for <mls@ietfa.amsl.com>; Sun, 25 Mar 2018 03:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NoFvtyW17ro5 for <mls@ietfa.amsl.com>; Sun, 25 Mar 2018 03:53:47 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org []) (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 E993B127599 for <mls@ietf.org>; Sun, 25 Mar 2018 03:53:46 -0700 (PDT)
Received: from [] (helo=[]) 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 1f03HQ-0007Sh-51 for mls@ietf.org; Sun, 25 Mar 2018 12:53:44 +0200
References: <a42925e5-6356-a686-1185-fbbfc5c730ba@a-oben.org>
To: mls@ietf.org
From: Simon Friedberger <simon.tls@a-oben.org>
X-Forwarded-Message-Id: <a42925e5-6356-a686-1185-fbbfc5c730ba@a-oben.org>
Message-ID: <77e637fe-635f-b696-879d-e99add067b03@a-oben.org>
Date: Sun, 25 Mar 2018 12:53:39 +0200
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: <a42925e5-6356-a686-1185-fbbfc5c730ba@a-oben.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/JcFORTeTATVi2v5faeJIknwdD1g>
Subject: [MLS] Fwd: Re: 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 10:53:48 -0000

(Copy to the list.)

Hi Eric!

>     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.
> OK. I guess Jon and others who run IM services can weigh in here on
> their experience, but
> I can tell you about Mozilla's experience in a not-dissimilar setting,
> namely browser sync.
> Firefox used to have a system which required interaction between the
> original device
> and the one to be enrolled, and we found it to be a very aversive user
> experience which
> we eventually abandoned in favor of a more conventional password based
> design.
Indeed that sounds much better. So how does this work? The user encrypts
their data with a password derived key and you use some form of
challenge response for authentication so you never get the password?

So for MLS this would translate to the service provider holding password
encrypted packets with pre-approved authentication keys from a known
good device?

Best Regards,