Re: [MLS] multiple devices per user?

[Jon Millican <[e-mail]>]

Hi Simon!

    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?

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'm not sure that devices being added is such a common occurence that it
    would prohibit asking for authorization from a different device.

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

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.

Hope that all makes sense,
Jon

On 25/03/2018, 00:07, "MLS on behalf of Simon Friedberger" <[e-mail] on behalf of [e-mail]> 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?
    
    
    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
    
    _______________________________________________
    MLS mailing list
    [e-mail]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=ydPgBsdbgSFYUFwdJm-6v92W8jfmRX0bLCWotiZUV74&s=tAKK3eoV3faD6isIxu8BorPdnMf6vO8m3jA9DMs6o94&e=