[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
- [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP Kai Engert
- Re: [ietf-privacy] Privacy of CLIENTID for IMAP/S… Nick Doty
- Re: [ietf-privacy] Privacy of CLIENTID for IMAP/S… Stephen Farrell
- Re: [ietf-privacy] Privacy of CLIENTID for IMAP/S… Fernando Gont
- Re: [ietf-privacy] Privacy of CLIENTID for IMAP/S… Benjamin Kaduk
- Re: [ietf-privacy] Privacy of CLIENTID for IMAP/S… Michael Peddemors
- Re: [ietf-privacy] Privacy of CLIENTID for IMAP/S… Kai Engert