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

From: Michael Slusarz <[email-masked]>
Date: Thu, 26 Aug 2021 00:47:14 -0600 (MDT)

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

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 26 Aug 2021 08:40:51 -0700

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.

"[email-masked]"

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 :)
> 
> _______________________________________________
> Extra mailing list
> [email-masked]
> 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.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 26 Aug 2021 18:22:40 +0200

Michael Peddemors wrote in
 <[email-masked]>:
 |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.
 |
 |"[email-masked]"
 |
 |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.

What a terrible sedition is that again, i wonder why that hate
speech always comes up again and again, and is allowed on public
lists.  While big players have not managed it to protect their
users by offering S/MIME or OpenPGP as part of their business,
still.  Really, i am so pi..ed by this, over and over again.
'Tell you what, i opened a PayPal account just a few weeks ago,
and i can tell you how easy it is when money is waving hello.

Luckily i have cold security on this box (Luks2), as well as warm
security (encfs on top, passwords in that PGP encrypted on top),
as well as hot security (slock on LID close, encfs umount on LID
close, ssh-agent key DB drop on LID close).

'Tell you what, i just wanted to get an OAuth verification for a
Unix console application, and it is just a chicanery.  You need to
create a youtube video to visualize things ... that this console
program just does not have!  I gave them a still frame like so

    #?0!0/NONE#|sn_gm:/var/spool/mail/steffen? File imap
  [I contact GMail]

    You need a passphrase to unlock the secret key for
    user: "Steffen Nurpmeso <[email-masked]>"
    4096-bit RSA key, ID A57802DD, created 2017-11-30 (main key ID 1883A0DD)
  [On the cold-security unlocked hard disk partition, on the
  cold/warm unlocked encrypted directory, there is a OpenPGP
  encrypted file where the passwords are stored.
  This file is unlocked here, the password comes from an agent
  running concurrently to the session you see]

    #?1!22/INVAL#|sn_gm:imaps://[email-masked]/INBOX?
  [We are now connected to GMail.  There is no mail]

So hey, support free projects which provide secure password
stores, i have heard you even donate a bit to keep TLS alive and
living!  Thank you!!  We have one major TLS, and a single major
PGP implementation on this earth -- thank you!!!!

Support standardized secure email containers.

Support refreshing of authentication tokens via normal TLS
transport, instead of requiring HTTPS that is HTTP 1.1 today, 1.2
tomorrow and 1.3 a day later.  Even omnipresent cURL that gets
a bit of donation i have heard slurps in support for 1.2 and 1.3
via external libraries because it is such a huge pile or work!
Even if there is relation in between the major head and QUIC, no?

Support EXTERNAL authentication, support CMS, support
authentication that interacts with security tokens.  Support live
refresh of certificates inside a TLS connection authenticated via
EXTERNAL.  Hey, support per-user server TLS certificates shipped
alongside the EXTERNAL certificate for the user, so that there is
a true and real point-to-point connection.

Or hey, create your own better-email that _you_ can make money
with?

All i want to use is my passport that comes from my country by the
way.

'Tell you what, i do not have any apps on the (used) smartphone
i have.  Hey, but do not ask me why.

And what do you mean with insecure?  My bank account uses
a four-digit PIN.  How secure is that???

Really.  You may feel cool when singing this sedition over and
over again, and it may bring you forward in your job.
Other than that .. really not.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)