[ietf-smtp] Good to see new list, comments about the "purpose"

Michael Peddemors <michael@linuxmagic.com> Wed, 29 July 2020 16:15 UTC

Return-Path: <michael@linuxmagic.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3C3A0D23 for <ietf-smtp@ietfa.amsl.com>; Wed, 29 Jul 2020 09:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 wzEusuPMqE4a for <ietf-smtp@ietfa.amsl.com>; Wed, 29 Jul 2020 09:15:28 -0700 (PDT)
Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6993A0BE7 for <ietf-smtp@ietf.org>; Wed, 29 Jul 2020 09:15:23 -0700 (PDT)
Received: (qmail 35858 invoked from network); 29 Jul 2020 16:08:43 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (c64a275e-d1b5-11ea-898d-47e5c5e1c2ab); Wed, 29 Jul 2020 09:08:43 -0700
To: emailcore@ietf.org, ietf-smtp@ietf.org, mailsec@ietf.org
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com>
Date: Wed, 29 Jul 2020 09:08:43 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: c64a275e-d1b5-11ea-898d-47e5c5e1c2ab
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/2pJdUD1i19ht1s49tuTB4X1cmE0>
Subject: [ietf-smtp] Good to see new list, comments about the "purpose"
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 16:15:35 -0000

I believe this is an opportunity, and the BOF should consider that the 
working group's mandate be extended larger than originally suggested.

As pointed out previously on other threads, having a working group that 
covers the whole email core, would enable this working group to tackle 
more wide ranging email problems, that are important to the internet 
community.

For example, the current conversation in the ietf-smtp mailing list, 
there are discussions about permitted labels' in email, that should 
properly encompass IMAP usage as well, same goes for the conversations 
about SSL vs STARTTLS, applies to both SMTP and IMAP.

Having a standing WG that can address issues across the whole email 
ecosystem makes sense.

And if that is true, again I purport the new WG could then take on:

https://tools.ietf.org/html/draft-yu-imap-client-id-04
https://tools.ietf.org/html/draft-storey-smtp-client-id-09

*Comments Welcome*

Someone (Dave) suggested we use a standardized template.


Item:        { Reference-name }

Issue:       { Concise description of problem, concern, or the like }

Effect:      { What significant effect(s) is this issue producing? }

Validation:  { Document the basis for the claimed effect }

Item: CLIENTID

Issue: Traditional IMAP/SMTP protocols are no longer sufficient for 
modern day threat protection, especially when it concerns traditional 
email and password authentication.  Malicious bots and attacks, and data 
breaches have made world wide users of email vulnerable to email account 
takeovers.  Password replay attacks, dictionary attacks, password reuse, 
and weak passwords are a very real and persistent threat.
Hacked email accounts are no longer just used to send spam, threat 
actors now use it for data exfiltration, spear phishing, deploying 
ransomware, and the takeover of cloud services, where the email address 
controls access, such as banking information, cloud services, domain 
name takeovers, impersonation, as well as access to sensitive 
information in email mail repositories, contacts, and other related 
information.

Effect: Adding CLIENTID to the base IMAP/SMTP protocols allow for ACL's 
and/or controls to only allow authentication to approved devices, and/or 
classes of devices, preventing password reuse/guessing attacks, which 
currently are attributed to be the major source of email compromise. 
This technology can be deployed transparently to the end user(s).

Validation: The CLIENTID extensions are already in wide spread use, 
across multiple email servers, and multiple email clients, and it's use 
detects and prevents > 99% of all such attacks against CLIENTID enabled 
email accounts.

As this is already becoming a standard across multiple vendors. and it's 
efficacy is proven, this would be the time to ratify the implementation 
standards.  For those that aren't aware, it's in public use in MagicMail 
and MailEnable servers, and it is supported in emClient, SaneBox, 
BlueMail, Thunderbird, and many other email client libraries.

I believe the IETF supports enshrining in RFC's standards that are 
already being adopted in the wild. And we are still looking for an 
official home for this, and the working group to take it on.


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