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, 9 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