Subject: [dispatch] [BACKGROUND] Request for Dispatch to discuss steps forward on email security issues.

From: Michael Peddemors <[email-masked]>
Date: Wed, 12 Feb 2020 16:18:17 -0800

For those that monitor other IETF lists, you may be aware that we were 
soliciting support for a "Birds of a Feather" surrounding issues that 
face the Internet today related to "Email Security".

* BEC (Business Email Compromise) are now the largest single factor in 
damage reported insurance claims.
* Email Compromises lead to higher rates of Ransomware, phishing, spear
  phishing
* Email compromise may lead theft of other resources (domain 
resets/transfers, banking password resets etc)
* High number of email clients and servers that still allow transmission
of unencrypted credentials.  Reluctance of operators to deprecate.
* Auto Discovery Methods may preferentially try insecure methods,
   exposing credentials
* POP Connectors maybe inadvertently leaking credentials

Several initiatives have been pushed forward, and several discussions, 
however it is not yet in a form that has clear enough definitions to 
decide on whether the requirements for addressing this within the IETF, 
dictate the formation of a new working group, or a re-purposing of 
existing ones, or expanding their mandates.

In our case, we are pushing forward on trying to make our proposals 
around CLIENTID extensions to both SMTP AUTH and IMAP, and that crosses 
boundaries of existing working groups.

It is my contention, that there are enough topics around email security 
in general, that while maybe first a BOF should be formed to clarify the
scope of such discussions, a working group be formed to solve these
serious issues.

And while we continue to see adoption of our SMTP AUTH and IMAP CLIENTID 
extensions, as outlined in our RFC Drafts, we would like to see this
become a standard, so it is more readily accepted and adopted by all 
email clients and servers.

This will take a working group that can encompass email security in a 
larger scope, than WG's only concerned with singular protocols.

Topics for Discussion -

* How/if/when should POP/IMAP/SMTPAUTH credentials being sent 
unencrypted be stopped?
* Should we deprecate language in RFC's that permit unencrypted?
* Common standards for AutoDiscovery methods for email clients
   (No AutoDiscovery is bad as well, as it encourages insecure)
* Advantages of using an extension to IMAP/SMTP AUTH to allow
   for a TOKEN that can be used as part of a two factor authentication
* Are there other authenticaton systems that would benefit as well?
* Why CLIENTID is better as an extension to the protocol, than a SASL
   implementation?

Some other ideas have also be floated, that is best suited to a working 
group with a wide enough scope to encompass these issues.

Given that we are NOT holding a BOF in Vancouver, it is suggested that 
we petition for time to be held in the DISPATCH session in Vancouver to 
discuss these things.

	-- Michael --

PS, we can still have a BOB ('BOF over Beers') session for those who are 
interested.

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