Subject: [Jmap] Alissa Cooper's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Wed, 20 Feb 2019 11:37:58 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-jmap-core-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-core/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 7.2 =

There is something I'm not understanding about this:

*deviceClientId*: "String" (immutable) An id that uniquely
      identifies the client + device it is running on.  The purpose of
      this is to allow clients to identify which PushSubscription
      objects they created even if they lose their local state, so they
      can revoke or update them.  This string MUST be different on
      different devices, and be different from other vendors.  It SHOULD
      be easy to re-generate, not depend on persisted state.  A secure
      hash that includes both a device id and vendor id is one way this
      could be achieved.

I don't understand why device ID needs to be incorporated in order to achieve
uniqueness here. Really it seems like what is needed is a unique ID per client,
full stop. Even if you have the unlikely scenario of two clients running on the
same device from the same vendor (say, one for mail and one for calendar), you
would still want to support the ability for each client independently to be
able to recover its push subscriptions, right? Some JMAP servers may have
device IDs for other reasons anyway, but setting this up this way seems like it
opens the door for clients to unnecessarily share device IDs with JMAP servers
in other cases.

Related to this, I don't understand the "SHOULD ... not depend on persisted
state." Why? I presume it would be straightforward to produce a unique client
ID that did not have the device ID embedded if this requirement were not there.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 1.1 =

Please use the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

= Section 2=

s/To avoid conflict, the identifiers for these MUST be a URL with a domain
owned by the vendor./To avoid conflict, an identifier for a vendor-specific
extension MUST be a URL with a domain owned by the vendor./

= Section 8 =

Depending on the outcome of the discussion related to the DISCUSS point above,
I think it would be appropriate to describe or even normatively require client
ID construction such that client IDs are opaque and can change over time at the
client's choosing.

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 20 Feb 2019 20:56:10 -0500

On Thu, 21 Feb 2019, at 06:38, Alissa Cooper wrote:
> uniqueness here.

Yes. This text was attempting to make clear that every instance of the client needs a separate id, but it needs to be stable. So if your client was "Mail App Foo" running on a phone with "UniqueIdX", combining these two pieces of information would give you an id that should be unique, but is none the less easy to regenerate.

> Really it seems like what is needed is a unique ID per client,
> able to recover its push subscriptions, right?

Yes.

>  Some JMAP servers may have device IDs for other reasons anyway, but setting this up this way seems like it opens the door for clients to unnecessarily share device IDs with JMAP servers in other cases.

The suggestion is to use a secure hash of a vendor string and device id, in which case it's unlikely to reveal useful information about the device id (presuming this id itself has sufficient entropy), but it's possible clients would do something else.

> ID that did not have the device ID embedded if this requirement were not there.

This is due to wanting to make sure you don't lose it and have to generate a new one, at least not very often. The reason for this is to make sure the client doesn't register itself twice. The only way it can know if it is currently registered for push notifications with the server is fetch the list of registered devices for the user and see if any of them have the same deviceClientId. For security reasons we don't return the push endpoint or encryption keys that were registered with the server, which are the only other things that could be used to correlate. If the client's id changes it can't know if it's registered and so may register twice and so start receiving every push twice, at least until that registration expires but that could be some time.

Sure, done.

> extension MUST be a URL with a domain owned by the vendor./

Updated, thanks.

Neil.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 22 Feb 2019 11:43:04 -0500

Hi Neil,

> On Feb 20, 2019, at 8:56 PM, Neil Jenkins <[email-masked]> wrote:
> 

Right, historically this is the kind of thing where some clients just send the raw device ID, which becomes a vector for tracking. I would feel more comfortable if there was a normative recommendation to use the scheme you suggest or something with equivalent obfuscation properties. But given your ‘Yes’ above, I don’t see how that works. Two clients from the same vendor on the same device will send the same ID. Isn’t that a problem? And how would a client know that it is a problem and generate the ID some other way?

Thanks,
Alissa

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Feb 2019 22:38:09 -0500

On Sat, 23 Feb 2019, at 03:43, Alissa Cooper wrote:
> Right, historically this is the kind of thing where some clients just send the raw device ID, which becomes a vector for tracking. I would feel more comfortable if there was a normative recommendation to use the scheme you suggest or something with equivalent obfuscation properties. But given your ‘Yes’ above, I don’t see how that works. Two clients from the same vendor on the same device will send the same ID. Isn’t that a problem?

The intention is you would use a string unique to your app that cannot conflict with another vendor. For example, suppose you were ACME Inc, and owned domain acme.com, and produced both a Mail app and a Calendar app. You might do something like this for your mail app:

sha256( device-id . "com.acme.mail" )

and like this for your calendar app:

sha256( device-id . "com.acme.calendar" )

What if I change the current wording:

*A secure hash that includes both a device id and vendor id is one way this could be achieved.*

to a stronger:

*It is RECOMMENDED to use a secure hash of a device id concatenated with a custom vendor/app id. **To protect the privacy of the user, id MUST NOT contain an unobfuscated device id.*

Would that work for you?

Neil.