Re: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP
Kai Engert <kaie@kuix.de> Mon, 09 September 2019 17:20 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 1B417120018 for <ietf-privacy@ietfa.amsl.com>; Mon, 9 Sep 2019 10:20:11 -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 zVOuMcOg2Mfo for <ietf-privacy@ietfa.amsl.com>; Mon, 9 Sep 2019 10:20:09 -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 9F8B4120811 for <ietf-privacy@ietf.org>; Mon, 9 Sep 2019 10:20:03 -0700 (PDT)
Received: from [10.137.0.12] (p5DD42757.dip0.t-ipconnect.de [93.212.39.87]) by cloud.kuix.de (Postfix) with ESMTPSA id 39A67184563 for <ietf-privacy@ietf.org>; Mon, 9 Sep 2019 17:20:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1568049601; bh=WJETsy5MlbdfIWl5pyT32oZTjdlkYfdZ9B9K+xrytps=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dXUgComLMe3zKKtYx5NyYr95ZCxbLXiLcPjM1iWt/NUcYqhI3zEf3yBe326dXkV9j RMXoUu5ET96EyJczU1ZKRE2qNRVAGX9Sc15/zi1ld1H46kGKTddN0DL/iFvynEfb+L ezFMmDBQKRiv5frerHJJ1qlU1ECHCS9progZuTbu2EHIAxvzLMj1bkIuI0XoL0P19i hXAMczmXNTg7k7yIksj7CUVy9r7uzwW1v9YJrmco6yFyeKTc9JSWNyBgA4G/unRCy1 ByrQGsSIO5ZAd86CmphWixjCFEv6X7Ng1PYlkcHWx6hE4q6L2Z2FOhtHNT9issjGCY v2njXCIfQzGKw==
To: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>
References: <ae89b75c-65c3-db47-8152-19ef3f96dcb1@kuix.de> <B4A437C0-0220-4649-87A1-B2B212B32CC9@ischool.berkeley.edu>
From: Kai Engert <kaie@kuix.de>
Message-ID: <f3ee278f-7007-4502-1112-e6cecfa4c61e@kuix.de>
Date: Mon, 09 Sep 2019 19:20:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0
MIME-Version: 1.0
In-Reply-To: <B4A437C0-0220-4649-87A1-B2B212B32CC9@ischool.berkeley.edu>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-privacy/vrD9jfG0OLXmsq6NphW3TVp0Xz4>
Subject: Re: [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, 09 Sep 2019 17:20:11 -0000
Thanks to everyone for your comments, in particular thanks to Nick for a very detailed response. There seems to be a broad consensus that the identifier used for CLIENTID must not be related to any hardware property, nor to any environment property, and it must not be predictable. Rather, the ID must be be random and must be separate per account. The ID should be changed whenever the account properties are modified by the user, like username or server hostname. The ID could also be changed if the server identifier changes, like the server's TLS certificate. The user should be able to reset the ID. The ID should be local, not shared with other devices. Assuming these requirements are met, no additional worries have been mentioned. Nick mentions a server might already be able to use heuristics to identify a user based on other attributes of interactions between client and server, and enabling CLIENTID might be an acceptable trade-off for many users. In my opinion, presenting an identifier on a silver tablet makes it much easier for a server to identify a client, because the indirect information might be less reliable, and it requires the server operator to actively implement collection of secondary attributes and building the heuristics. In other words, even if identification might already have been possible, it required work and still involved uncertainty, while the introduction of CLIENT makes identification very easy without additional investment. On the other hand, the web uses HTTP Cookies, and it was helpful that Nick mentioned them. With cookies, we already have a broadly accepted mechanisms that servers can use to recognise a client. Although it isn't the server who defines the CLIENTID, and the server cannot control what's stored inside CLIENTID, it might be appropriate to compare the privacy implications. While many servers and clients support cookies, we've also seen a lot of worry about cookies, which even resulted in legislation in the EU that users must be shall be made aware whenever cookies are used. It might be reasonable to treat CLIENTID similarly as cookies. This means, in addition to what has been said already, it might be useful to inform the user whenever a server makes use of the CLIENTID feature. Thanks again. 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