Re: [Mailsec] [Extra] Advanced ("Modern & Secure") Email Authentication

[Michael Peddemors <[e-mail]>]

Hi Michael,

For the record, there is a new (relatively) mailing list that has low 
volume, but I might suggest that this discussion belongs on that list.

"[e-mail]"

It is a good topic for that list.  I heard about this initiative, and it 
seems interesting, and while I am still not convinced that utilizing our 
CLIENTID addition to the protocols belongs in some of the ideas..

"The goal is to educate on the interplay between already existing
standards like Email SRV records (RFC 6186), OAUTH/OpenID autodiscovery
in SASL (RFC 7628), and expected authentication flows in the various.. "

I do think it is an important topic, give the very real and present 
dangerous problems surrounding email authentication.

Once again, we should be all striving to use the IETF to discourage poor 
practices still widely used today.

	-- Michael --


On 2021-08-25 11:47 p.m., Michael Slusarz wrote:
> Hello all,
> 
> First, let me echo Bron and say congratulations and thank you to 
> everyone that helped IMAP4rev2 become reality, especially Alexey and 
> Barry as editors!  You have all created a substantial additional amount 
> of work for me in coordinating efforts to ensure compliance with the new 
> standard :)
> 
> Onto my main topic: I am looking for input regarding the proper forum to 
> raise an initiative we are currently working on.  Very short background: 
> within the last year, many of our largest customers have come to us 
> asking what can be done about making authentication for email services 
> more "modern and secure".  Specifically it is driven by the desire to 
> stop using the legacy username/password paradigm to authenticate to core 
> email backend services, but more abstractly the problem can be framed as 
> a more general desire that "email services should do authentication like 
> current mobile/web apps do".  (JMAP implements advanced auth, but our 
> customers require support for the legacy mail protocols.)
> 
> Our initial focus was on figuring out the best way to better support 
> "modern & secure authentication" - which we took as a mandate to spread 
> universal availability and adoption of delegated authentication and all 
> the benefits it provides.  Yes, this kind of exists today in some 
> clients for a very small subset of providers (Gmail, Yahoo, etc.) - but 
> the proper general solution cannot be hard-coded authentication 
> endpoints in select clients for select email providers.  There needs to 
> be access to a universal standard, or at least a best practice, that 
> allows any mail installation to enable advanced authentication and then 
> have immediate client access to this improve functionality.
> 
> And if we are going to spend time and energy trying to convince the 
> ecosystem to support this, we might as well rethink the entire user 
> email authentication experience at the same time.  Wouldn't it be great 
> if (best case) a user installs a client, enters just an e-mail address, 
> and the client does all the auto-configuration necessary behind the 
> scenes to connect to the proper server and display the user the "login 
> page" for their account, which would allow any kind of fancy modern 
> security desired (2FA, etc.)?  We believe all of the necessary standards 
> already exist to accomplish this today.  We believe it is just a matter 
> of educating developers/admins on how to consistently implement this goal.
> 
> The goal is to educate on the interplay between already existing 
> standards like Email SRV records (RFC 6186), OAUTH/OpenID autodiscovery 
> in SASL (RFC 7628), and expected authentication flows in the various 
> email protocols (IMAP, POP3, Submission, ManageSieve) that would enable 
> client authors, server authors, and administrators to provide the 
> necessary infrastructure to enable widespread adoption.  This feels like 
> an Informational document, not a Standards Track document, as the intent 
> is to provide a best practices way to use and link multiple concepts 
> rather than inventing new functionality.
> 
> The question I ask today is: what is the proper WG to take discussion on 
> this idea?  I bring the idea to extra as this is an e-mail centric WG 
> and there is specific overlap in this proposal with several of the email 
> protocols addressed by this WG (IMAP, ManageSieve).  But, admittedly, 
> Submission and POP3 are currently out of scope here, and this proposal 
> also touches on areas like DNS, OAUTH/OpenID Connect, and SASL.
> 
> I did consider taking this to direct to dispatch, but wanted to get 
> input from the email community first, with the thought that if anybody 
> else here is interested in the same problems that they should feel free 
> to join us in pushing this forward :)
> 
> Thanks, and looking forward to any/all feedback.
> 
> michael
> 
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra
> 



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