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 (mich...@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 mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
