Re: [MLS] multiple devices per user?

Eric Rescorla <ekr@rtfm.com> Sun, 25 March 2018 00:27 UTC

Return-Path: <ekr@rtfm.com>
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 74931126C83 for <mls@ietfa.amsl.com>; Sat, 24 Mar 2018 17:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 wwqcwuArnVr6 for <mls@ietfa.amsl.com>; Sat, 24 Mar 2018 17:27:49 -0700 (PDT)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A121812025C for <mls@ietf.org>; Sat, 24 Mar 2018 17:27:49 -0700 (PDT)
Received: by mail-ot0-x235.google.com with SMTP id g97-v6so17073335otg.13 for <mls@ietf.org>; Sat, 24 Mar 2018 17:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pwhhz9LC773qdgB3joT/NnMmPgO0P1TTiApYCjN9GgQ=; b=a80CCNGmqUK/DYPK35YhOyQQGep6ndmfa1krhp3et8j+DpenI2XieaunM9fhjprKRD boAJBLKoJ+K/LTKA9QDSVhbA/dg7qz6Muzl957eLtaCJj7c/BK3umWU6UIbzwckBRGbT /Zbu4k1pXAwI7ZLyBo0IQZjB8Mam9j1v/7MAMDSeWQfso7vCegfdWV/vX5DSGDw6NvxN uwZX2QClBy8omc2LpBQ4EOYUxIPwWYXV7Xmkdx9HjVQu99pcGC8erRxRJ5oJidXjWO2Q IFszq+a/Ggn/ozYHpeJq74kCBzleGzVl6eyQVO5eGM5Z2FrJp3klSWP3NK7MJ3eHFUQ3 pVUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pwhhz9LC773qdgB3joT/NnMmPgO0P1TTiApYCjN9GgQ=; b=tqyUpDrnnKnPZJZmY1K4veQ08o5ge6WiUlvbM5iM0pgTTbCimWfuDiJhdvQy1LTv0E jFZW/Aq8tYyF2aJYqoxDakdROfLpvwluvx3V5DYpVSbZIieKpK8R4m2ky8WbWDzf5U0T sKrtc5wIQdI6vNczO4T83mXAgwxTzvmUWD8f6G53Wt2kNne5hnzFa8KILAEgLo93V7BK J5N5fsc4MiwT0z/b9/hbNf1RliaHSbcR3EhW/91uznzJeEi4c0UmEhMtD/pAW5jTBSdS 0nejP0Avs5i8DkkqVjD1OteE4w0Kai+bh6j6VSHd5MckC/srzVUM0TYNruGoJwvOKQqg 2xfg==
X-Gm-Message-State: AElRT7FmUnQXyDs6l9Mrb/WcVoVSkQZ6rEOBBU15lQMcjEvtik3cLmXc MarpgEyTljI7loNWjJaU8rd5gTb9FbGY68KAT31GmiOl
X-Google-Smtp-Source: AG47ELu+xqCUetFQQuZX0t3ntghLzR+IYRNO52OmeBt71WYvNomM1CJ/nemDGSHvAZ/qrfSdm9c736cJ/HyUx51Y+qI=
X-Received: by 2002:a9d:26d4:: with SMTP id i20-v6mr19128312otd.214.1521937668755; Sat, 24 Mar 2018 17:27:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.23.21 with HTTP; Sat, 24 Mar 2018 17:27:08 -0700 (PDT)
In-Reply-To: <b2ce2ddd-02e7-3161-dd97-fee31684366d@a-oben.org>
References: <87efk9m7e9.fsf@fifthhorseman.net> <CABcZeBOAaA2_SRSimo2-x-jCw=YjvDsU7h0kPzU9WroTBBHoKA@mail.gmail.com> <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> <b2ce2ddd-02e7-3161-dd97-fee31684366d@a-oben.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 25 Mar 2018 00:27:08 +0000
Message-ID: <CABcZeBNO8gc2CkJKEkhcos9fXBfmU21AUWNy51b2M=y3dVesZQ@mail.gmail.com>
To: Simon Friedberger <simon.tls@a-oben.org>
Cc: mls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001de849056831ba50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Cx0yVBeXrksP6MxKDXam-RKzCOw>
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:27:51 -0000

On Sun, Mar 25, 2018 at 12:06 AM, Simon Friedberger <simon.tls@a-oben.org>
wrote:

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

Just for clarity, I assume you mean a MITM attacker who controls the
authentication server, right



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.



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?


I've been assuming that systems that wanted to offer strong guarantees some
form of key transparency so that users could determine which other devices
were registered to their account.



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


No, I don't believe so.



> i.e. check at random
>
intervals if the list is still correct?
>

I'm not a UX designer, but this isn't the UX I had in mind. Rather, I was
expecting
that the app would notify you when a new device was registered. This is
already
the UX that many Web sites provide for situations when you log in on a new
browser (though that's for cases when the threat is password compromise
which
is why it's safe to offer via the browser or email, rather than in the app).

-Ekr






-Ekr


>
>
> Best Regards,
> Simon
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>