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

Jon Millican <jmillican@fb.com> Sun, 25 March 2018 13:21 UTC

Return-Path: <prvs=66228ba95d=jmillican@fb.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 77C5A1250B8 for <mls@ietfa.amsl.com>; Sun, 25 Mar 2018 06:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ftpORkgT; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HjEsduME
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 UUu3CsQdEm1X for <mls@ietfa.amsl.com>; Sun, 25 Mar 2018 06:21:47 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 C3DAD1205D3 for <mls@ietf.org>; Sun, 25 Mar 2018 06:21:47 -0700 (PDT)
Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w2PDJRWx023216; Sun, 25 Mar 2018 06:21:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=wGjLnelOf+apbBMvqPzwXhsSlbW2vDPc3MTpIMBYrQM=; b=ftpORkgTJ7oXqU/4GlIcEOe8ErE96kZuS5rD3L27iq3aEFT5gxvleyJzzHjOU64kCTzP paRyKKjSMYIlaCHr135AC0BEVjm1OZGypRtJ+T94y0R3ecFCNt0vBzPJWeQf3T0amxoZ z76FCknX+/Wa6B/v/wOr+1mxLRtv1aD56IU=
Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2gwj5ysum3-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2018 06:21:40 -0700
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 25 Mar 2018 09:21:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wGjLnelOf+apbBMvqPzwXhsSlbW2vDPc3MTpIMBYrQM=; b=HjEsduMEBmfxhDuBWKTCGDqfr3DTc1t4pk7jMt2TmAR12Qy7wTwMjM1akGpIaVLz+v4F4nXSW6M5oD5/bO7i1fI7Kz7R4vpP3DeKK6awoM5L7oFv9JNzQzrQAWFEioJez8NJEE5ocpB+JQY4dJK7ED2aLwfETh9BJF0CeH8/VJk=
Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1942.namprd15.prod.outlook.com (10.172.180.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sun, 25 Mar 2018 13:21:37 +0000
Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0609.012; Sun, 25 Mar 2018 13:21:37 +0000
From: Jon Millican <jmillican@fb.com>
To: Simon Friedberger <simon.tls@a-oben.org>, "mls@ietf.org" <mls@ietf.org>
Thread-Topic: [MLS] Fwd: Re: multiple devices per user?
Thread-Index: AQHTxCe5vIFKcpQrPkCN3YGVCqXYYKPhANuA
Date: Sun, 25 Mar 2018 13:21:37 +0000
Message-ID: <0273A6A6-A491-4DC2-9B07-8B048EE4B537@fb.com>
References: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de> <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org>
In-Reply-To: <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [82.39.102.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR15MB1942; 7:eH+TF18qLdH0tgX+R2aU0PNhRCmx9mmto0jQ+duCCE7v4O3rBmUPB42XyMsbYJvwwMMgRPQMDM4o1G+6XfTcl2JLnLMg9SCw7lo4b0hJGMIiKZFBF8Rs0njcxo2Pbfo/wCxK0KgV5zr5hcp4sm2/TTYLMgYw23JfDBuQMIQLmrADLHujTgQ7+ldEPxCbJp9/8KZ1WcdRLHqaz1r152mS4O9t9MGRuEl1uVoyCoRHuTXPedZkvfvhTg65VrakTU6G; 20:eBLAszTjZkWKdvlLBPFAPm8oA4fdL1+ZfOU+dXsubYzpSWBSCa/37BJXppjC8Wh4VwyxFeAIrJFS7iWyUj24UTGaoMpRAZpBM5hw+HzjweptnUUDB/j79PLnpF6FL4BK7CieEZwsaXnDk5KE2iSBZC/mxN2/bLK8AY8UOHod4Wo=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: da8930f0-5953-4e31-8b66-08d5925356b2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1942;
x-ms-traffictypediagnostic: CY4PR15MB1942:
x-microsoft-antispam-prvs: <CY4PR15MB194231745CB9D2077F4C4F14DAAE0@CY4PR15MB1942.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(81227570615382);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR15MB1942; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1942;
x-forefront-prvs: 0622A98CD5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39860400002)(39380400002)(396003)(51444003)(189003)(199004)(51914003)(99286004)(76176011)(110136005)(8676002)(59450400001)(8936002)(6506007)(81166006)(81156014)(2900100001)(106356001)(102836004)(14454004)(55236004)(26005)(186003)(966005)(83716003)(3280700002)(105586002)(478600001)(3660700001)(2616005)(2906002)(446003)(11346002)(36756003)(68736007)(5250100002)(82746002)(66066001)(3846002)(6306002)(6512007)(229853002)(2501003)(25786009)(316002)(86362001)(575784001)(6116002)(575854001)(53936002)(5660300001)(97736004)(7736002)(53546011)(33656002)(6486002)(6246003)(6436002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1942; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OqMby6n0Y7zqD1ZepuSq8tqbByB5I7SUGhqQz8sp5vAjxTKQ0dT3ufZDXl9A4aQj29ufVy8/hhATZG5LGwxOCdpd4ofdJHO6z+cCKjHWveWIWVfosDxxAHdRR1VDcHQXhoI9zZq1xuVArMOPJywIFu+t2VdFYNyNBQDToderbKAMWkCcyIys0pZ6+nif63cpuhInhj2MwuQSQR1maNAX823GS4LAzTNcHF9YFwxVThwj7xDQa7KgLzJgPp4bDMcgeB+hFTjCbfsHshlh9yVKIRjJ6Zw0mIpPJGSj6qEUoHt946vIjlhkmzK7JS4FMUzIhZglHkdKYSZ525XDzJRirQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <49209C99D609C14A93EB7B0A19C0FFA4@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: da8930f0-5953-4e31-8b66-08d5925356b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 13:21:37.5869 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1942
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-25_06:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/xNFv-zX0AVwJayd_0qs0pDzRfPk>
Subject: Re: [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 13:21:49 -0000

Hi Simon,

Thanks for the comments. I understand your point of view, and have at times advocated for many of the same suggestions. Hopefully the context below will help to clarify our design choices.

    I think having the partners deal with new devices is the wrong approach.
    They probably don't know if a user has new devices so adding trust to
    devices should be handled by the users with the devices.

As I say, this is a specific use case in which we require devices to work immediately on log in. I absolutely accept that comparing long strings of random characters for all device changes is a difficult ask; but unfortunately in this specific case, requiring users to explicitly enrol a device from another wasn't feasible.

    I think the cases of replacing devices and adding them should be treated
    differently. In the latter case trust has already been established and
    can be transferred. In the first case, which is the case you are
    concerned with, there is no trust and it should be an implementation
    detail to highlight this to the user so the protocol should not make
    them equivalent.

This cuts to the reason why explicitly enrolling devices from trusted devices would be difficult for us. It's a common situation in which the original device is no longer available for whatever reason (lost, stolen, broken, sold, etc), so new devices that people log in to simply wouldn't be able to use Secret Conversations without choosing to explicitly enable the new device for it. Not only does this make things harder for people who explicitly plan to send an E2E message, but it means that people who don't know about the E2E mode will simply become inaccessible over time as they upgrade devices; and those people who do explicitly want to use Secret Conversations won't be able to reach their friends who are unaware of/uninterested in the feature. I'm not speaking in hypotheticals here; the original version of Secret Conversations worked in exactly this way: it was single-device per user, so if you replaced your phone, you would have to explicitly enable Secret Conversations on the new device, otherwise the enrolled device for your account would remain as the one that was enabled when we originally rolled out the feature. Over time, it was easily observable that people would become inaccessible via the feature, which ultimately was a barrier in the way of E2E communications, encouraging people to instead use normal Messenger conversations. Enabling multi-device, and the behaviour described above, fixed this issue, and you can now usually expect people on Messenger to be accessible via Secret Conversations.

    But that only works with some form of key transparency, right? Otherwise
    the device list can easily be manipulated.

Right: without transparency it's plausible that a service can present a split world view. This is why our threat model currently focuses on knowing where your messages are going. However viewing your own devices in this way allows you to at least see where your own messages are going (if foul play is happening on your own account, you need to know about the additional devices).


We've definitely had to make trade-offs in the design of this feature, but I'd be surprised to hear if any app hadn't had to make trade-offs. However, I'm certainly not advocating that MLS should be centred around our specific use case. I think that ours is one that's worth supporting; but that the use cases across the ecosystem of secure messaging apps are equally important to support.

Thanks,
Jon

´╗┐On 25/03/2018, 11:55, "MLS on behalf of Simon Friedberger" <mls-bounces@ietf.org on behalf of simon.tls@a-oben.org> wrote:

    (Resent because I had the wrong sender address.)
    
    
    Hi Jon!
    
    
    On 25.03.2018 01:48, Jon Millican wrote:
    > I think this is likely application-specific, but in our case we surface all device list changes within E2E threads, and you can look at the specific device public keys if wish. If you see that I have a new device, you can thus - in theory - ask me out of band whether the key is legitimate. The relevant part of our threat model here is "you should know what endpoints you're sending messages to before you send the message", so this fulfils that requirement.
    I think having the partners deal with new devices is the wrong approach.
    They probably don't know if a user has new devices so adding trust to
    devices should be handled by the users with the devices.
    
    
    > In our use case, this is common. Whenever somebody logs in on a new device, there's a strong chance that they don't have access to the previous one at the time - and won't want to be blocked from using Messenger until they can authorise the new device - particularly if it's a replacement phone for example. As Facebook Messenger itself is not an E2E app in the general case, we wouldn't want to add additional barriers that discourage people from using Secret Conversations.
    I think the cases of replacing devices and adding them should be treated
    differently. In the latter case trust has already been established and
    can be transferred. In the first case, which is the case you are
    concerned with, there is no trust and it should be an implementation
    detail to highlight this to the user so the protocol should not make
    them equivalent.
    
    
    > I think I addressed this above, but we let people know when new devices are added to their account. Those who wish to can go check the list of devices on their account at this point.
    But that only works with some form of key transparency, right? Otherwise
    the device list can easily be manipulated.
    
    
    Best Regards,
    Simon
    
    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=8JRh1KhcQfJkoXk7A_lTeGcdowgEi1M3B5NIbAHUZiY&s=b9hD5HuIChXtR8WJqJtQ2bUNn_eC2NlGc5pnUh4hz2A&e=