From nobody Wed Jul 22 08:56:29 2020 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 1326D3A0978 for ; Wed, 22 Jul 2020 08:56:26 -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 NXUwjIYlwEhz for ; Wed, 22 Jul 2020 08:56:24 -0700 (PDT) Received: from mail-ob3.cityemail.com (unknown [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFFD3A0962 for ; Wed, 22 Jul 2020 08:56:21 -0700 (PDT) Received: (qmail 13250 invoked from network); 22 Jul 2020 15:56:21 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (e2e2e540-cc33-11ea-90d0-7fe6812030b9); Wed, 22 Jul 2020 08:56:21 -0700 To: ietf-smtp@ietf.org, mailsec@ietf.org References: <579f408c-ed7e-9dbe-f626-f0dab2380d13@isode.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <2841d94c-07c8-c90b-70f4-e74fca55eb5e@linuxmagic.com> Date: Wed, 22 Jul 2020 08:56:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <579f408c-ed7e-9dbe-f626-f0dab2380d13@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: e2e2e540-cc33-11ea-90d0-7fe6812030b9 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] [ietf-smtp] Proposed agenda for EMAILCORE BOF X-BeenThere: mailsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 15:56:27 -0000 I would also like to again talk about CLIENTID in email core as well. We recently started a 'mailsec' mailing list, and currently just pushing for more people to get on that list, that is specifically interested in email security issues, however with an 'email core', we should discuss if some of those elements have a cross over. Since it is obvious that extensions to SMTP are being considered, and since this is 'email core' and not just SMTP anymore, the CLIENTID extension for SMTP/IMAP should be considered as part of that (smtp extensions) discussion. For the record, we now have many email clients, and email libraries supporting CLIENTID as it stands in the present RFC Drafts, making this already a defacto standard, which is something that the IETF I believes uses as a litmus test for things that should be supported/pursued by the IETF. CLIENTID support is in the wild, with our MagicMail platforms, as well as other platforms are in various stages of supporting it (MailEnable et al) and modern email clients like SaneBox, BlueMail, emClient, Thunderbird and more are already shipping with CLIENTID support. As well, I do see that the topics I suggested for the 'mailsec' mailing list, eg discussing no longer suggesting the use of POP 110, or SMTP AUTH on port 25, (eg no use of protocols that are not SSL/TLS enabled) is also listed as a topic for this BOF. Welcome comments on the overlaps, and suggestions on how to administratively best address that overlap. On 2020-07-22 4:49 a.m., Alexey Melnikov wrote: > Revision of core Email specifications (emailcore) agenda for [virtual] > Madrid. > > > WEDNESDAY, July 29, 2020 (UTC) > 11:00-12:40 (1 hour 40 mins) > > > Agenda bashing, introduction, meeting format (chairs) -  5 mins > Problem statement (chairs) -  5 mins > > Review of proposed changes to "Internet Message Format" (RFC 5322) > draft-resnick-rfc5322bis - 15 mins > >  Issue with ABNF for "field": https://www.rfc-editor.org/errata/eid2950 >  Disallow empty quoted string: https://www.rfc-editor.org/errata/eid3135 >  Header field name length limit: https://www.rfc-editor.org/errata/eid5918 > > > Triage of raised issues for "Simple Mail Transfer Protocol" (RFC 5321) > draft-klensin-rfc5321bis - 10 mins > > Example topics (we tackle as many as we have time for) > >  G.9.  Revisiting Quoted Strings > >  G.7.11.  Bring back 1yz reply codes? > > Core Email Applicability Statement: - 35 mins > >  G.6.  Clarify where the protocol stands with respect to submission and >        TLS issues > >    1.  submission on port 587 or port 465 > >    2.  TLS relay on a port different from 25 (whenever) > >  Suggested SMTP Extensions: >   G.8.  Enhanced Reply Codes and DSNs >   8BITMIME >   SMTPUTF8 (a.k.a. EAI) > >  Terminology: >   G.3.  Meaning of "MTA" and Related Terminology >   G.7.2.  SMTP Model, terminology, and relationship to RFC 5598 >   G.11.  SMTP Clients, Servers, Senders, and Receivers > >  G.1.  IP Address Literals in EHLO, MAIL or RCPT > >  G.7.3.  Resolvable FQDNs and private domain names > >  G.10.  Internationalization Consideration section needed? > > > High level discussion of how the proposed WG going to decide > which issues to tackle (chairs) -  5 mins > > Charter Review and discussion (chairs) - 25 mins > > > > Documents: >  https://datatracker.ietf.org/doc/draft-resnick-rfc5322bis/?include_text=1 >  https://www.rfc-editor.org/errata_search.php?rfc=5322&rec_status=15&presentation=table >  https://datatracker.ietf.org/doc/draft-klensin-rfc5321bis/?include_text=1 >  https://www.rfc-editor.org/errata_search.php?rfc=5321&rec_status=15&presentation=table >  https://datatracker.ietf.org/doc/draft-klensin-email-core-as/?include_text=1 > > --------------- > If we go too quickly through triage of some issues, here are some others > that > we can discuss: > > G.5.  Remove or deprecate the work-around from code 552 to 452 > >    The suggestion in Section 4.5.3.1.10 may have outlived its usefulness >    and/or be inconsistent with current practice.  Should it be removed >    and/or explicitly deprecated? > > G.7.1.  Issues with 521, 554, and 556 codes > >    See new Section 4.2.4.2.  More text may be needed, there or >    elsewhere, about choices of codes in response to initial opening and >    to EHLO, especially to deal with selective policy rejections. > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp -- "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 Wed Jul 29 09:09:07 2020 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 C68E73A0D36 for ; Wed, 29 Jul 2020 09:08:52 -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=ham 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 S2Um9eDQ8Q14 for ; Wed, 29 Jul 2020 09:08:49 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 407DB3A0D81 for ; Wed, 29 Jul 2020 09:08:44 -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 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: X-Archive: Yes Archived-At: Subject: [Mailsec] Good to see new list, comments about the "purpose" X-BeenThere: mailsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 16:08:58 -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. From nobody Wed Jul 29 09:19:36 2020 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 C018D3A09E1; Wed, 29 Jul 2020 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 zRLuqbCYMOiR; Wed, 29 Jul 2020 09:19:24 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 0E56D3A094E; Wed, 29 Jul 2020 09:19:14 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06TGLo5E001815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2020 09:21:50 -0700 Reply-To: dcrocker@bbiw.net To: Michael Peddemors , ietf-smtp@ietf.org, mailsec@ietf.org References: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> Cc: emailcore@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <70a175d5-c32b-9096-7203-996475054f48@dcrocker.net> Date: Wed, 29 Jul 2020 09:19:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Mailsec] [ietf-smtp] Good to see new list, comments about the "purpose" X-BeenThere: mailsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 16:19:27 -0000 On 7/29/2020 9:08 AM, Michael Peddemors wrote: > 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. That would be an excellent way to avoid getting the primary task done, which is to get the two, primary specification elevated to full standard. It's a variation on attempting to boil the ocean. It's not that the larger scope isn't worthy, it's that it isn't practical. After the primary task is completed, it might make sense to consider rechartering, for a scope of the type you suggest. But not before then. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net