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

From: Michael Peddemors <[email-masked]>
Date: Wed, 29 Jul 2020 09:08:43 -0700

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: Dave Crocker <[email-masked]>
Date: Wed, 29 Jul 2020 09:19:07 -0700

> more wide ranging email problems, that are important to the internet 

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Jul 2020 14:48:25 -0400

> It's not that the larger scope isn't worthy, it's that it isn't 

Agree.  There's also a real potential for it to be a Pandora's box.

Keith

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Jul 2020 15:09:10 -0400

On 7/29/2020 12:19 PM, Dave Crocker 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.
>
>

Dave,  I agree with you, keep the eye on the prize, RFC5322/5321 
standardization. Very important.  I'm sure there will be plenty of 
"Heads Up" discussions, items that can perhaps be phrased as 
implementation notes.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jul 2020 21:35:17 -0400

Hi.

Some observations and an attempt to play devil's advocate:

(1) If we are going to have a separate list, let's have a
separate list, not create confusion by copying ietf-smtp and
having both the additional clutter and the risk of parallel
discussions.  So, while this note is copied to ietf-smtp for
obviously reasons, I hope it will be the last, or nearly-last,
cross-posting.

(2) Perhaps I'm the only one, but I'd really like to try to
survive this week without putting something else on my virtual
plate.  So I would encourage others to just let this go until
next week (or longer).  In any event, for myself, please don't
expect further responses from me until at least the weekend.
And I would encourage not reading the rest of this note until
those who would do so have recovered from this week.

(3) Now the substantive part (and, for most of it, the devil's
advocate part):

Personally, I'm fine with the model of focusing on moving
5321bis and 5322bis to Internet Standard, using a separate {
Applicability Statement | BCP | Rubber Ducky } as a way to
accommodate whatever behavioral recommendations, comments on or
pointers to other specifications, and/or "roadmap" materials for
whatever mail-related specifications the WG concludes are
important.  As Pete said during the BOF about 5322[bis], I'd
really, really, like to get 5321[bis] off my plate, do so before
I retire [1], and do so with a minimum of pain and suffering.
The current plan appears to me to be the best way to accomplish
all of that.

_However_...
Despite a BOF that was organized around that narrow scope and
focus, not only is it not the only way forward but it may be
based on a false premise.  RFC 6410 dropped the standards track
from three maturity levels to two in the hope that would result
in significantly more documents moving to Internet Standard.  A
handful of specifications that have been advanced without
changes to the underlying documents aside, it is rather clear
that has not happened and that, if anything, the Internet and
the users of IETF specifications care even less than they did
nine years ago.   I do care on grounds of tidiness; Pete,
Alexey, Seth, and Barry presumably care, and probably others
reading this care, but it is not clear that any significant
number of relevant others care.  And, while that narrow focus
may be the fastest way to get the work it defines done, it will
still be a fair amount of work; the BOF today provided evidence
that some things will be controversial and painful to resolve;
and so on.  The payoff may not be sufficient to justify that,
which suggests two other possibilities.

(a) RFC 5321 is a bad document (so was 2821).  It is really a
merge of three separate documents combined with excerpts from a
fourth and some added applicability statement material
associated with the technical specification.  In part because of
that merge and the age of RFCs 821 and 974, it switches
organizational styles and writing style from section to section.
The switch from the textbook BNF of RFC 821 to the ABNF of 2821
introduced errors; the transition to 5321 did not catch all of
them and may have introduced some new ones (see Appendix H,
Section H.1, of draft-klensin-rfc5321bis-03) and there is no
good reason to be confident that there are none left.  And, as
was sort of mentioned during the BOF, the references between the
two documents for syntax and the greater permissiveness of 5822
contribute to confusion.   Two consecutive WGs (DRUMS and YAM)
decided against doing a full rewrite --largely on the grounds
that it would take more time and risk more errors -- but, if we
really want to add value in this iteration, maybe we should be
developing something more like:

  (i) A complete rewrite of 5321
  (ii) An update to 5322 more or less along the lines planned --
material in 5322 only has one core document and two editors in
its history while I count about eight authors/editors for what
became 5321 -- but with some material torn out.
  (iii) A consensus, best practices, terminology and model
document using RFC 5598 as a starting point.
  (iv) A syntax specification that draws on both 5321 and 5322
and that is referenced by both.
  (v) A "roadmap" document for Internet email specifications,
possibly combined with A/S and/or BCP material for some of those
specs.  Or those could be one or more documents separate from
the roadmap.

Other breakdowns are clearly possible, but the goal would be to
recognize that we have something of a mess on our hands and that
part of the goal for producing Internet Standards is to make
them clear and easy to understand, a goal that actually requires
more than the narrow revisions now proposed.

(b) As any of us with experience in this area should have been
able to predict (and several of us did), mentioning the idea of
opening up 5321 and 5322 immediately drew multiple topics out
for consideration for inclusion in one or the other document (or
something related).  Maybe that energy is A Good Thing. If so,
perhaps we should put the efforts to get 5321bis / 5322bis to
Internet Standard aside for six months or a year (or longer) to
give those proposals time and attention sufficient to get clear
documentation and IETF consensus on whether or not they are good
ideas and then to be able to demonstrate interoperability, wide
deployment, etc., only then coming back to 5321bis/5322bis when
we are ready to make substantive (rather than procedural)
decisions about their inclusion.  That time might also allow
some already-published specs to mature sufficiently to be
incorporated or normatively referenced.

Again, I'm not suggesting either (a) or (b) above, but they
appear to me to be plausible alternatives that we should
consider and, if appropriate, reach consensus to explicitly
reject rather than blowing them off because they are
inconsistent with the path we have been on.

best,
   john

[1] Something that is feeling a lot closer right now than it did
last week.