Subject: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP

From: Kai Engert <[email-masked]>
Date: Mon, 19 Aug 2019 18:07:48 +0200

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

---

From: Nick Doty <[email-masked]>
Date: Mon, 19 Aug 2019 14:57:16 -0400

Thanks for sharing the proposal and the implementation ideas.

I can definitely see security advantages to this kind of approach. By sending an additional identifier along with a username and password, a server can more reliably recognize clients it has seen before, and that kind of information is a useful heuristic and mitigates some of the risk of password disclosure. I think app-specific passwords were a similar approach, but required overloading the password field.

Adding any client identifier, even one transmitted only over a secure channel, does potentially disclose information about the user to the server. I agree that there is a disclosure of the kind where the server can learn about the number of the user’s devices or something about their habits. That might be an acceptable trade-off for many users, especially because some of that information is likely already available to the server, which uses heuristics like IP address, or particularities of how different email clients work, to recognize variations.

But I am especially concerned about the suggestions for different types of identifiers in these drafts. Sending a permanent or semi-permanent hardware identifier (like the MAC address or other hardware ID) is especially dangerous:
* it’s necessarily shared between accounts and users of the same device, disclosing correlation between accounts;
* it’s less useful for security purposes because, if it’s disclosed to the attacker, it can’t easily be changed;
* the user can’t easily change it when they want to clear their identity information;
* it allows for collusion between servers to identify two accounts at two different servers as connected to the same device;
* it unnecessarily reveals other information about the user’s device, like the hardware vendor, and sensitive information that may be used as an authentication signal in other protocols or for other purposes.

While these drafts don’t require hardware identifiers, recommending it as a type of clientid is dangerously unhelpful. License keys also seem like a poor suggestion: they aren’t necessarily one-to-one with devices, they reveal extra information about the user’s software, they’re unlikely to change and they’re shared across servers. It’s not clear why different types of identifiers are useful at all; it certainly makes the privacy and security properties harder to analyze. The drafts even suggest disclosing information (like the vendor) in the named type of the identifier! Standardization could improve interoperability as well as user privacy.

These privacy threats of identifiers and potential mitigations are well-described in RFC 6973 [0] and I believe additional I-Ds on numeric identifiers are also under development.

We could spend more time reviewing what the persistence, scope and user control of identifiers is appropriate. Off the top of my head: a pseudorandom (and therefore “unintelligent": revealing no other information about the user) unique number generated by the client for every user/account-server pair; resettable by the user whenever they choose; reset whenever the user rotates other client identifiers; stored by the client on the local device and not synced to other devices. 

Forgive my Web-centricness, but HTTP cookies (and more specifically, newer proposals to replace them [1]) have given some experience in the privacy advantages of limiting the scope to an origin (maybe roughly analogous to the mail server) and limiting persistence and intelligence.

Hope this helps,
Nick

[0] https://tools.ietf.org/html/rfc6973#section-6.1
[1] https://tools.ietf.org/html/draft-west-http-state-tokens-00

> On Aug 19, 2019, at 12:07 PM, Kai Engert <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Aug 2019 21:05:21 +0100

Hiya,

I didn't read the drafts, but Nick's comments make sense to
me so I'd give those a +1 (modulo not having read the draft
of course:-)

One other thought...

On 19/08/2019 17:07, Kai Engert wrote:
> If the client

Sometimes I've been prompted to accept a hotspot's bogus
certificate for IMAP if my MUA is the first to trip over
a hotspot. A user might hit yes in such a case which is
a bad idea yes, but I guess happens. I guess an active
attack could appear similarly.

So is there a reason to tie the CLIENTID to the server
credentials I wonder? E.g. to rotate it whenever the
server cert changes. That might also discourage servers
from assuming that the CLIENTID never changes.

However, were I asked what I'd like to see in TB and
IMAP servers, it'd be some usable (i.e. invisible:-)
way to do an SSH-like IMAP authentication, so the
server doesn't need to have a listener that accepts
password based auth at all. (I have a number of VMs
where the IMAP/SUBMIT ports are the only ways into
anything that still accept passwords.)

So, instead of a CLIENTID, I'd love to see TB generate
a key pair when you add the account and for the user to
only have to use the IMAP password at that stage and
not every time the MUA connects to the IMAP or submit
server. And rotate that key pair every N connections.

Any chance of that instead? (He asked cheekily:-)

Cheers,
S.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Aug 2019 23:46:54 +0300

Hello, Kai,

> * https://tools.ietf.org/html/draft-storey-smtp-client-id

I suggest you take a look at these I-Ds:

* https://tools.ietf.org/html/draft-gont-numeric-ids-history
* https://tools.ietf.org/html/draft-gont-numeric-ids-generation
* https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations

They are meant to provide analysis and solutions for this an other
numeric IDs.

FWIW, there's an ongoing call for adoption (please see here:
https://mailarchive.ietf.org/arch/msg/pearg/YlTn3VlnwFbnJ0IgNLTtLwg6W0c), on
the PEARG list (https://www.irtf.org/mailman/listinfo/pearg).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Aug 2019 21:59:02 -0500

> from assuming that the CLIENTID never changes.

I was going to say something similar.  So, a "yes" from me :)

-Ben