[Pearg] Numeric IDs (Fwd: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP)

[Fernando Gont <[e-mail]>]

Folks,

As you can see, the topic comes up over and over again (when it does!
Because in all other cases, the outcome is simply flawed numeric IDs).

This is the reason why we produced the set of documents on numeric ids
(https://mailarchive.ietf.org/arch/msg/pearg/YlTn3VlnwFbnJ0IgNLTtLwg6W0c)

Thanks,
Fernando




-------- Forwarded Message --------
Subject: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP
Date: Mon, 19 Aug 2019 18:07:48 +0200
From: Kai Engert <[e-mail]>
To: [e-mail]

Hello,

I would like to ask for feedback on potential privacy concerns related
to the following drafts, that describe a CLIENTID feature for the IMAP
and SMTP protocols:
* https://tools.ietf.org/html/draft-yu-imap-client-id
* https://tools.ietf.org/html/draft-storey-smtp-client-id

The Thunderbird project is currently evaluating a request to support the
CLIENTID feature and enable it by default.

We'd like to ensure that we appropriately consider all potential privacy
issues that could arise as a consequence, prior to making decisions
about inclusion or default behavior.

Here is my quick summary of the CLIENTID feature:
* an email client creates a random client side identifier for itself,
  and stores it locally.
* at the time a client starts a connection with an IMAP or SMTP server,
  which the user has configured for accessing or sending mail, the
  server may ask the client to send a client identifier. If the client
  supports it, and if the connection is encrypted, then the client
  sends its client side identifier.
* the client ID doesn't replace the regular login credentials,
  but shall be treated as additional information about the client
  accessing the server.
* servers want to compare the client ID that is received on a
  connection, and draw the conclusion that the current client is
  the same client that has connected to the server in the past.
* the intention of the authors of the drafts is to make it easier
  for the server side to detect fraudulent login attempts.

We have already identified that reusing a single identifier across
multiple email accounts could allow a server to learn that those email
accounts are controlled by the same entity, and we don't want to allow
that. Consequently, Thunderbird would use a different client side
identifier for each account.

What are additional privacy concerns?

If multiple client computers are used to access the same email account,
this feature allows the server to distinguish the different computers.

For example, a user might regularly use two different computers to
access an email account, one computer at location A, and the other at
location B.

If both locations use a dynamic Internet connection with changing IP
addresses, as of today, the server probably cannot distinguish which
location was used to send an email. However, with the CLIENTID feature,
the server potentially could.

The server could use the CLIENTID feature to learn about habits. For
example, if emails from location A are primarily sent during daytime,
and emails from location B are primarily sent outside regular office
hours, the server could learn that the computer at location A is at an
office, and the computer at location B is in a private apartment.

Consequently, the server operator could draw conclusions where the user
was located at the time an email was sent.

Can you think of additional negative consequences for the user's privacy
with CLIENTID enabled?

Thanks in advance
Kai

_______________________________________________
ietf-privacy mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-privacy