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

Kai Engert <kaie@kuix.de> Mon, 19 August 2019 16:07 UTC

Return-Path: <kaie@kuix.de>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F8D120130 for <ietf-privacy@ietfa.amsl.com>; Mon, 19 Aug 2019 09:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.de
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 dg6mnlohO65r for <ietf-privacy@ietfa.amsl.com>; Mon, 19 Aug 2019 09:07:52 -0700 (PDT)
Received: from cloud.kuix.de (cloud.kuix.de [IPv6:2001:8d8:1801:86::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3527120131 for <ietf-privacy@ietf.org>; Mon, 19 Aug 2019 09:07:50 -0700 (PDT)
Received: from [10.137.0.12] (ip-178-203-233-33.hsi10.unitymediagroup.de [178.203.233.33]) by cloud.kuix.de (Postfix) with ESMTPSA id BE612183A69 for <ietf-privacy@ietf.org>; Mon, 19 Aug 2019 16:07:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1566230868; bh=4Z8+ivM1rZPWSLrEViI/QpY5ivK+F1qWhmdx4Umqc2Q=; h=From:Subject:To:Date:From; b=oQR2cjauNTNBv2aIrJDXy2jN4UOrntkJ1GrYftS4ZzrGFM5MMRTukpNZK8BKWL9zS CnIz9pdG8bM6KU5e5N5b2Rf06Edr2J2ma2mgG4MY7s94I2QdEswnOZ/7mLanGDRnLD kI2jaXYN+ciZ/M8kujGY+wpRsGLHXqAD65bS5Aspvat0zv0j5/CNtA21OQRcxxiPvG YayInYcw5yoMOvtQXUBTDPOQtSdtNJ27PrcrCXCnqg42IEQwPwFxpM3p+0CZzFY0vP Zjje255R6Q+DTiIvgNtSbmDTVTGqk8hHkVZHz6S6gzpieNTG8HSS4wM+HqQzHKPvnI K0FWdtmEvPbqQ==
From: Kai Engert <kaie@kuix.de>
To: ietf-privacy@ietf.org
Message-ID: <ae89b75c-65c3-db47-8152-19ef3f96dcb1@kuix.de>
Date: Mon, 19 Aug 2019 18:07:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-privacy/OWa0cztXmhGexs0tZXraMhZM6VY>
Subject: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2019 16:07:54 -0000

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