On 2022-07-14 10:12, Michael Slusarz wrote:
On 07/07/2022 5:24 AM Aki Tuomi <aki.tu...@open-xchange.com> wrote:

FWIW I think OAuth2 is the modern way to do actually MFA authentication.  There is some 
progress in Mozilla world (and hopefully other mail clients) to allow OAuth2 to work 
outside the "big three" circle. Mostly this is *client development issue*, the 
server-side already mostly supports all the bits you need to roll your own MFA with 
OAuth2 using off the shelf components. No need to pay microsoft or google.

Alternate to OAuth2, which works pretty well today, is to use device passwords.

A bit late to the game, but wanted to expand a bit on Aki's comments.

It's good that this topic is being discussed.  We've long felt that email authentication 
(and, related, client auto-configuration) is one of the biggest weaknesses of email as 
compared to more "modern" messaging technologies.

However, discussions around this topic tend to get sidetracked as everyone wants to try 
to design their own technical solutions.  However, all the necessary technologies exist 
and are standardized.  Token auth is handled by OAuth2.  MFA ,and more generally 
authentication UI, is handled by OpenID Connect.  At the mail protocol levels, token auth 
is handled by SASL.  Additionally, SASL supports auto-discovery of authentication 
providers so there is no need to "hard-code" OAuth2 providers (the unfortunate 
way that some clients are currently handling OAuth2).  Dovecot supports all of these 
technologies already, so there's nothing left to do on the server side.  (Side note: 
client auto-configuration is also already fully supported using existing technologies as 
well.)

Instead, the issue is chicken/egg - all of this is worthless until 
clients/providers start implementing this.  That's where the focus of efforts 
need to be, not in trying to determine which technologies to use.

Admittedly, this not insignificant paradigm shift can be a bit confusing technically.  
It's been a long-standing TODO to create some kind of implementation guide to help 
server/client/auth providers to understand what they need to do to create this new 
"modern email authentication" ecosystem.  This is a classic example of a 
situation where necessary standards exist, but the education about these standards are 
lacking AND there remains open questions about how those standards should interact with 
each other in real-world scenarios.  Dynamic client registration in OpenID Connect, in 
particular, is a key component to make this work but is somewhat under documented and 
lesser known, so it will take community involvement, and likely trial and error, to 
determine best practices.

TL;DR from a Dovecot perspective: we feel we have all the necessary components needed to 
enable "modern email auth" in the current product, so we don't see any 
additional engineering efforts needed in Dovecot.  We instead are focusing our attention 
in building and supporting a broader community of client authors and authentication 
providers to push for implementation in order to accomplish the goal.

michael

p.s. As mentioned by Aki, app-specific/device passwords is a perfectly 
acceptable solution, although a bit of an end-user usability nightmare.  It's a 
hack to improve security today, but not a proper long-term answer.


Thanks for weighing in Michael,

.. but if you wish to enable developers and innovation, you do need to foster the ability for other parties to use plugins, advertise other methods, etc.. there are still many that feel oAuth might not be the right approach, and while anyone can be an oAuth provider, that this might centralize.. As it is, we already see in North America the insurance companies wording for '2FA' requirements check boxes sounds a lot like 'Are you using o356?'.

I believe Dovecot can be a leader, in ensuring that the future doesn't just consist of a few central players..

You might 'feel' that you have all the necessary components, but of course that does come from a business perspective, and it doesn't allow for new, novel, or innovative ways that 3rd parties are coming up with everyday.

(and in the case that we are working with, there are already several clients and servers that support it)

Dovecot I personally believe, given it's over 70% market share, does have a responsibility to remain open and collaborative, otherwise it risks being perceived as rigid as some of the big commercial proprietary products.

By 'deciding' for the world what is sufficient for 'modern email auth', this is limiting.. IMHO

To quote that old Linux Torvald saying.. "Let a thousand flower bloom.."

Noone has to agree on everything, or approaches.. but enable them to get out into the real world, and amazing things may happen..


Have a great weekend everyone.. get out in the sun..



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

Reply via email to