Subject: [Extra] CLIENT ID - Next Steps - General Discussion Overview

From: Michael Peddemors <[email-masked]>
Date: Mon, 23 Jul 2018 11:27:34 -0700

Thanks once again for allowing us to present at the IMAP EXTRA group,
and now that everyone is back home, it is a good time to reflect on the
discussions surrounding CID (Client ID) in IMAP, as we concluded that
there was not yet enough consensus around this, and we agreed to open
up dialogue/discussion on the list, so that we can argue for, and
hopefully gain consensus on that it should be part of this groups'
mandate.

And I have to thank everyone for all the comments, and appreciate your
patience as we go through this process, and the 'mentor' comments from
Alexey, Bron, John and others.. It helped us better understand
separating the 'process' from the ideal of the CID proposal.

It seemed that the group understood the later, without the need for me
to 'champion' the idea as much.  I think everyone in the group
understood, and with everyone looking at or implementing methods to
allow traditional services to have the capability of at least alerting
users to when unexpected/new access to a service is detected, we should
consider that if everyone 'sees the value of this capability', or 'is
already trying to do this', that creating a 'standard' for this is
good for everyone, and the IETF is the correct venue for setting the
standards, whether it is this working group or another. (Albeit, we will
argue that this group is currently the right place for this based on
that the 'syntax' for IMAP is separate from all other services, and 
other arguments)

However, there were several items brought up that should be discussed
as separate issues and threads, so I propose that some of these get
discussed separate to the arguments on the correct 'home' for CID.

Some points brought up:

* CID Naming, several persons pointed out that this can become confusing
   as IMAP uses that type of name for other purposes.  I will start a
   separate thread on this topic, as it should be open for discussion.

* Security Notes, it was brought up that we left the idea of what
   CID Types and Tokens as open ended, and available to email client
   developers to have the flexibility to make decisions on what should be
   a token.  It was suggested we add more information to the security
   section, eg reminding developers to consider that Cid identifiers
   might be created in a way that they are unique to a hostname and/or
   service.  And while this isn't really part of the core draft, it does
   behoove us to have conversation on this topic, and I will pass this on
   to the author, but probably best to allow discussion on this topic.

* Discussion on whether the purpose of CID can be served via the ID
   command (RFC2971), and a separate thread has been started on that
   topic. (Thanks Timo)

* It was questioned, is the proper place for this in a SASL mechanism,
   vs in the protocol itself, and while our development work and research
   show that the advantages for a 'device identifier' to be part of the
   protocol/syntax rather than a SASL, and our assertion this will help
   in the adoption curve in the industry, it was one of the strongest
   points of contention, with the arguments for SASL, was one SASL can
   apply to many services, and thus if that argument holds, then maybe
   the SASL or a security group would be better for this.  We intend to
   argue against this, but the topic alone is key to discussions, so it
   requires a separate thread to discuss this.

* Outside of the meeting, mention was whether there is a reasoning that
   some form of general working group be considered that applies to all
   the standard email protocols, eg SMTP (Submission Only), IMAP/IMAP-SSL
   and POP/POP-SSL etc, however that is for others way beyond me to argue
   and I prefer to leave it out of this discussion.

* While it might seem like 'lobbying', it might be worth assessing who
   considers the concept worth pursuing/implementing as well as having
   others who are trying to solve the problem in other ways, to have a
   general discussion on what they are doing, or which methods that they
   prefer, as this might aid in validating that the need has enough
   people working on this that it does indeed need to be standardized.
   But would like the opinions of others with more IETF experience to
   determine if that conversation should be pursued here. As pointed out
   we have had conversations with other IMAP implementors that have
   voiced opinions that they could see themselves implementing this.

* Some conversation was help that the CID 'TYPE' might need to be
   defined, and whether CID 'TYPE' should be become 'registered' types,
   if indeed standardization is the goal, and while the suggestion is
   appreciated, sounds like putting the cart in front of the horse, and
   whether it would be better to let IMAP client developers have more
   freedom.  I think this can be left until later in the discussions.

In summary, the first four (4) bullet points, would be better discussed
separately, and I will be following up in separate threads to the list.
As pointed out, we strongly believe that CID goes beyond the mandate of
SASL mechanisms, but it is obvious that is the fundamental point of
contention that needs to be resolved and argued, as our perceived
importance of it being outside of SASL has at least not yet clearly been
communicated so others can argue the merits of this, so I expect it to
be the most discussed bullet point, but we of course can continue our
own movement forward by addressing the other points in the mean time,
including draft updates, and our own implementations.

Once again, we thank all for their comments and their support, as we
work through this process.

-- 
"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.

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 23 Jul 2018 15:53:45 -0700

>   separate thread on this topic, as it should be open for discussion.

The naming conflict is with the "cid:" URL scheme defined in RFC 2392. 
This acronym has been in use in the mail community for over 20 years 
with the specific expansion "content-ID". So just don't abbreviate 
"client id" as "CID" to avoid confusion.

>   to the author, but probably best to allow discussion on this topic.

Standards exist to promote interoperability when software comes from 
different vendors. So the semantics of a client ID have to be specified 
in sufficient detail so both the client software and the server software 
knows what to do with it. Flexibility is fine up to a point, but "client 
from vendor A provides a tag+string" and "server from vendor B does 
something arbitrary with tag+string" is not acceptable to achieve 
interoperability. The semantics must be nailed down to the point where 
there is at least a mandatory-to-implement model that will interoperate.

>   requires a separate thread to discuss this.

We have a case where client-id facilities (device-specific token, a 
subset of the client-id problem) were deployed in production using 
custom SASL mechanisms on our server and custom changes to a client. So 
I assert this is a proof-of-concept that SASL is deployable for 
client-id, that it can solve the problem for multiple protocols with one 
specification and shared code (Submission & IMAP), that it comes with an 
extensible capability model for interoperability, and does not break 
interoperability with unmodified clients. Furthermore, no custom changes 
were required to our server to support this since we have a SASL 
abstraction API we support. That means our customers could deploy a 
SASL-based mechanism without requiring a server upgrade, thus 
significantly simplifying deployment. We do not have an API for IMAP 
commands and have no intention of providing one, so our customers will 
not be able to deploy client ID unless it is SASL or there is an IETF 
rough consensus around a non-SASL client-id model for 
submission+imap(+pop+managesieve+jmap+etc).

I consider it unfortunate this use case involved proprietary SASL 
mechanisms so I'd support a standardized mechanism, but we have running 
code showing a SASL approach is deployable and backwards compatible.

I'm aware of another deployed use of client-id like facilities for push 
notifications.

>   and I prefer to leave it out of this discussion.

This proposal presently covers submission+submissions services and 
imap+imaps services. We need to consider the architectural implications 
of multi-protocol support. But I don't see a reason to move this 
discussion to a different forum at this time.

>   voiced opinions that they could see themselves implementing this.

I support IETF work to address this problem in a fashion that promotes 
interoperability.

>   freedom.  I think this can be left until later in the discussions.

Since this group tends to be very applied (as in shipping code), I think 
you'd do better if you at least provided more concrete examples of how 
to use client id in an interoperable fashion. SASL is a great example -- 
there are a small number of deployed standard mechanisms (PLAIN, 
EXTERNAL, GSSAPI/Kerberos to a lesser extent) but proprietary/custom 
mechanisms are allowed.

		- Chris