From nobody Thu Aug 26 08:41:05 2021 Return-Path: X-Original-To: mailsec@ietfa.amsl.com Delivered-To: mailsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1873A0E97 for ; Thu, 26 Aug 2021 08:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGj_Whlk1dVa for ; Thu, 26 Aug 2021 08:40:55 -0700 (PDT) Received: from mail-ob3.cityemail.com (unknown [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id D8F353A0E81 for ; Thu, 26 Aug 2021 08:40:52 -0700 (PDT) Received: (qmail 21731 invoked from network); 26 Aug 2021 15:40:51 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (ECDHE-RSA-AES128-GCM-SHA256 encrypted) SMTP (fe48a244-0683-11ec-ba7b-d7ee3740935b); Thu, 26 Aug 2021 08:40:51 -0700 To: extra@ietf.org, Michael Slusarz , mailsec@ietf.org References: <1898235280.14467.1629960434945@appsuite.open-xchange.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Thu, 26 Aug 2021 08:40:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1898235280.14467.1629960434945@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: fe48a244-0683-11ec-ba7b-d7ee3740935b X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Mailsec] [Extra] Advanced ("Modern & Secure") Email Authentication X-BeenThere: mailsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email Security Issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 15:41:04 -0000 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. "mailsec@ietf.org" 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 > Extra@ietf.org > 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 nobody Thu Aug 26 09:29:14 2021 Return-Path: X-Original-To: mailsec@ietfa.amsl.com Delivered-To: mailsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47AF3A08D7; Thu, 26 Aug 2021 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZcmrDkxLxnL; Thu, 26 Aug 2021 09:29:02 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97DA3A09FC; Thu, 26 Aug 2021 09:22:45 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 61F5D16056; Thu, 26 Aug 2021 18:22:42 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 98DD8C98; Thu, 26 Aug 2021 18:22:40 +0200 (CEST) Date: Thu, 26 Aug 2021 18:22:40 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Michael Peddemors Cc: extra@ietf.org, Michael Slusarz , mailsec@ietf.org, Steffen Nurpmeso Message-ID: <20210826162240.oxpLH%steffen@sdaoden.eu> In-Reply-To: References: <1898235280.14467.1629960434945@appsuite.open-xchange.com> Mail-Followup-To: Michael Peddemors , extra@ietf.org, Michael Slusarz , mailsec@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.22-175-gc118a4a5c7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Mailsec] [Extra] Advanced ("Modern & Secure") Email Authentication X-BeenThere: mailsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email Security Issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 16:29:08 -0000 Michael Peddemors wrote in : |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. | |"mailsec@ietf.org" | |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 " 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://sdaoden@imap.gmail.com/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) From nobody Thu Aug 26 14:58:03 2021 Return-Path: X-Original-To: mailsec@ietfa.amsl.com Delivered-To: mailsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054FA3A07DA; Thu, 26 Aug 2021 14:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_SUBJECT=1.799, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQRJF7DugtDa; Thu, 26 Aug 2021 14:57:37 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9130C3A07DE; Thu, 26 Aug 2021 14:57:35 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 6712616056; Thu, 26 Aug 2021 23:57:32 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 30952CA3; Thu, 26 Aug 2021 23:57:30 +0200 (CEST) Date: Thu, 26 Aug 2021 23:57:30 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Michael Peddemors Cc: extra@ietf.org, Michael Slusarz , mailsec@ietf.org, Steffen Nurpmeso Message-ID: <20210826215730.ispdH%steffen@sdaoden.eu> Mail-Followup-To: Michael Peddemors , extra@ietf.org, Michael Slusarz , mailsec@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.22-175-gc118a4a5c7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: [Mailsec] (no subject) X-BeenThere: mailsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email Security Issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 21:57:42 -0000 Subject: Re: [OFFLIST] Re: [Mailsec] [Extra] Advanced ("Modern & Secure") Email Authentication # Removing or modifying In-Reply-To: breaks the old, and starts a new thread. # Assigning hyphen-minus - creates a thread of only the replied-to message In-Reply-To: <9b64aff9-d9fa-f374-a302-25edc1922648@linuxmagic.com> Michael Peddemors wrote in <9b64aff9-d9fa-f374-a302-25edc1922648@linuxmagic.com>: ... I apologise to have addressed you -- it rather should have been sent primarily to the original poster. And in general it was possibly a bit over-reacted. But ..hm.. not that much. I already read mails from administrators stating to me "i now use X" when setting free my mail account, and i understood that Signal. It is just that i personally get angry when even better security is spoken ill of, whereas people sit in front of browser code bases of dozens of millions lines of code, with enabled Javascript, and logging into accounts via HTTPS and Cookies that have been set months ago. I at least use two totally separated browser sandboxes for normal browsing (everything but x) and "secure" browsing (everything with an account, etc, where that profile directory is an encrypted directory). But i think this is not normal, i think the default is people using one browser instance for anything. Of course, this is nothing the IETF can improve. Since JMAP was the starter of this thread, i guess the time where "anything is an object accessible via an omnipotent protocol that is spoken also by browsers" is not that far off. In sofar clamping client possibilities now that the protocol is omnipotent is the right way to go. Nothing the IETF can do about (no?). An interesting topic for user interface providers, configuring firefox just to turn off all the things is an experience, what if i would have a smartphone with dozens of apps, and my service provider would present me with a long list of switches to configure access of that app when i use it the first time to contact service provider a, b, c? Wow! (In fact i _cannot_ configure firefox right, it is just too messy. Someone pointed me to the uMatrix Plug-In, and i use it, it really helps -- it is the only plugin i have. One would not think _how_ messy even the simplemost web pages are, and from _how many_ different providers they slurp in scripts, graphics, and whatever else. It is just a huge pile of crap! _How can this be secure??_ And scripting everywhere, and "most modern" other things, where the results could have been implemented pre-Y2K with the CSS available by then. Etc. etc.) Again apologies for addressing you as the primary receiver! --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)