Re: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP
Michael Peddemors <michael@linuxmagic.com> Thu, 22 August 2019 18:17 UTC
Return-Path: <michael@linuxmagic.com>
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 ABBE5120A87 for <ietf-privacy@ietfa.amsl.com>; Thu, 22 Aug 2019 11:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.2
X-Spam-Level: *
X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_A1=3.099, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 DouU839Q6E6b for <ietf-privacy@ietfa.amsl.com>; Thu, 22 Aug 2019 11:17:21 -0700 (PDT)
Received: from fe2.cityemail.com (mail-ob2.cityemail.com [104.128.152.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF2DA120904 for <ietf-privacy@ietf.org>; Thu, 22 Aug 2019 11:17:20 -0700 (PDT)
Received: (qmail 6036 invoked from network); 22 Aug 2019 18:17:20 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe2.cityemail.com with (AES128-SHA encrypted) SMTP (14778102-c509-11e9-b7ad-00188b456935); Thu, 22 Aug 2019 11:17:20 -0700
To: ietf-privacy@ietf.org
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <22695a33-bbac-7181-6317-f6166ac34ee8@linuxmagic.com>
Date: Thu, 22 Aug 2019 11:17:19 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: 14778102-c509-11e9-b7ad-00188b456935
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-privacy/ezmpk5k52YyYE2GYzfAvKETavVo>
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: Thu, 22 Aug 2019 18:17:23 -0000
Replying to Nick.. Sorry, late to the party, but welcome this thread. We are still hoping to find an appropriate IETF 'working group' for these drafts as well, and this might encourage that.. the 'extra' working group had decided that it was beyond the mandate of that group, and it was suggested a 'security' group might be better suited to handle this.. While we do not see that the use of CLIENTID in itself is a privacy issue, especially given that it is an interchange between two parties that are probably governed by a terms of use (eg the person and their email provider) discussing the merits of what is contained in a CLIENTID constitutes a healthy discussion.. To your points.. <quote> 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. </end quote> As a contributor to these drafts, in hind sight even "mentioning" MAC address as a possible choice that someone might decide on to use as CLIENTID has turned into a lightning rod for concern. While the draft was intended to show that the identifier should be up to the implementation, eg that a email client developer should be able to choose what is the preferred identifier to uniquely identify a device, and not be limited to a specific form of identifier, some misread that possibility as a recommendation. I 'can' see a use case, eg a manufacturer of IoT devices might have a reason for identifying the hardware (thousands of temperature/moisture reading devices designed to send email alerts for instance) where they want this MAC information, eg to allow/revoke privileges when devices are lost/stolen/replaced, but I don't expect it to be a common choice, and would assume that they would take into consideration the issues surrounding using an identifier in an environment that may be easily be abused, or they correlate that information for other reasons.. It was meant solely as a discussion point and example. But let's leave aside any discussion of using MAC for a CLIENTID, until someone has a use case for actually doing that, and under what conditions.. * Hardware identifiers for devices of course should not be used for devices that are designed for multi-user capabilities, eg a desktop.. IMHO * While a hardware identifier may be difficult to 'replace', it is easy to 'revoke' privileges associated with a device when lost/stolen/replaced. I could see that someone might say, 'I lost my phone, so I don't want it to access my email any more, until I find it.' One thing that appears to be repeated in these discussions, and I think it muddies the waters, that an 'identifier' is a privacy concern. Aside from the fact that email historically has always used identifiers, such as IP Address, EHLO, TLS information that 'could' be abuse to become a privacy concern, it is only a privacy concern if the data was shared or used in a fashion it wasn't intended. That possibility of abuse (which would be a privacy concern) should not be confused with the technical merits. For example, we all hear about the possibility that it is technically possible for Google to determine exactly where you were standing when you checked your email already, by combining data points they have access to, and while that might be 'scary' to some, it is only a privacy concern, IF they do something unexpected or unauthorized with that data, eg sharing it with 3rd parties, or doing something outside of the terms of use for that service. There are many 'identifiers' that are healthy, but can be abused. ( I am sure your Android phone already has enough ways to identify that two accounts are using the same phone if companies 'collude' but there are privacy laws that prevent such activity for ANY identifier. This identifier simply makes the ability to say 'these devices are approved to access my account'. Eg, I only want the identifier that accurately indicates it is my laptop, my phone, my home computer, and my office computer, to be used when accessing my email account. And frankly, I would prefer if my 'trusted' email provider who promises not to share this information (just like I expect them not to share my email password, or credit card, or what IP(s) I access it from) as per the terms of use we agreed to when I signed up, DID provide me with obvious information about the device, so when I look at my device history, I can see which ones should be allowed. While it is technically possible in SOME environments for an email provider to gather some information, it isn't always easy for every email provider. (eg, gathering OS Fingerprints etc) For instance, I just had an 'alert' delivered to my mailbox, based on the fact it wasn't one of my approved devices, as evidenced by the CLIENTID. <notice> Hello, This is an auto-generated system alert. Your account (michael@linuxmagic.com) had an access attempt rejected. Device Signature: POP3 Client, Windows (Unknown Mail Software) Authentication: Failure IP Address: 192.3.11.68 Country Code: US Date: Thu, 22 Aug 2019 07:31:35 -0700 (another example) Device Signature: SMTP Client, Windows (Unknown Mail Software) Authentication: Failure IP Address: 190.55.39.156 Country Code: AR Date: Thu, 22 Aug 2019 08:44:06 -0700 Don't recognize this activity? If this WAS you, or one of your devices and you are travelling, or have a new device, visit the 'Security Settings' in your webmail or portal from a known registered device, and adjust your restrictions and/or permitted devices accordingly. -- Automated Security Notification System -- Note: The location is approximate and determined by the source IP address of the attempted login. DO NOT REPLY TO THIS EMAIL. </notice> Frankly, many use cases, eg tighter corporate email environments, closed email environments, might want information contained in the CLIENTID to be made available to the end user, eg exactly WHAT mail software was used, or what type of device was used. This kind of information is already available at the largest providers, but is not available as a general rule of thumb. I can see that some email clients, or devices MAY wish to provide more information so their users can more easily make their own determinations instead having to manually compare random strings to each device settings. All in all, the DRAFT itself is meant to be flexible enough for all use cases. It will be up to the email client developers to decide what information best suits the purposes of their customers use cases. But nothing stops that email client developer to use a completely anonymous string like a UUID if they think that is best.. *Phew* a lot longer email than I planned.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
- [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