Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats

On 2020-02-03 2:44 p.m., Eliot Lear wrote:
> Hi Michael,
> 
> IMHO the issue is not one of client identity, but rather preauthorization versus non-prearranged communication.  As to your recommendations below, while there’s nothing wrong with them, even if you implemented them, I do not believe that spam would be reduced one iota.
> 
> I would suggest that one delve a bit into per-destination preauthorization and how that might work from a UX perspective.
> 
> In any case, I’m not sure a formal BoF is called for at this point.  Maybe a bar bof.
> 
> Eliot

I do want to point out, this is not about spam, but rather email 
security, unless you are recommending that we enlarge the topic that much?

And BTW, for the record the CLIENTID is only one of many email security 
related topics that might be discussed.  Looking in general to see if 
others think that there are important things to add/avoid in this topic 
for a BOF.

(off thread, sending authorization is about validating ones identity to 
access an email resource, CLIENTID is a step in that direction, when 
used to that affect, but it can also relate to a class of 
allowed/expected devices that can access/authenticate to access a resource)

> 
> 
> 
>> On 3 Feb 2020, at 22:06, Michael Peddemors <michael@linuxmagic.com> wrote:
>>
>> Call for Feedback:
>>
>> "Birds of a Feather (BOF)" on email authentication security.
>>
>> As some may know, we have a couple of IETF Drafts looking for a Working Group home, but because it crosses over several protocols, discussions on these can extend beyond groups which cover only one protocol. There are some issues that extend across the ecosystem.
>>
>> These (our) drafts are related to email security, but as we look at this serious problem (email compromises), I believe it might be time to look at the problem in a wider scope, so I am looking at having a "Birds of a Feather" meeting proposal, that can encompass a wider discussion on IETF involvement in these issues.
>>
>> For instance, aside from our IETF drafts on CLIENTID extensions/enhancements for IMAP/SMTP AUTH, (for those not familiar, references at the bottom), there are other things that could be addressed in such a meeting.
>>
>> * POP/SMTP authentication sent unencrypted over the network
>> * AutoDiscovery should NEVER test unencrypted methods
>> * Email Clients should deprecate the above
>> * Other ideas to address email compromise risks worldwide?
>>
>> Given that in todays climate, of millions of compromised devices on the internet designed to 'sniff' traffic, sending authentication over the clear IMHO should NOT be recommended or referenced in RFC's, otherwise vendors will continue to support these.  We still see 'pop connectors' by 3rd parties, various auto-discovery methods that attempt to connect using POP 110, all whom send email credentials in the clear, risking unintended exposure of this data.
>>
>> All modern email clients have a role in protecting users, and by supporting such legacy methods, these risks will continue.
>>
>> While some new RFC materials cover the SHOULD be over encrypted, and some cover recommendations, a larger discussion in general over whether updates should occur, to deprecate language that would allow for insecure transmission of authentication protocols.
>>
>> And aside from our own methods to make a more transparent form of native ability in legacy protocols to support tokens that be sent before authentication credentials are received, to allow systems, users, and authentication tools to decide whether to accept authentication requests unless supported by a recognized token, there may be others working on improvements in security that crossed protocol boundaries, or address other security related threats in email.
>>
>> My question to the list is this:
>>
>> * How wide/narrow should the topic/mandate be?
>>
>>   -- Email Authentication & Security
>>   -- Communication Authentication Security
>>   -- POP/IMAP/SMTP Authentication
>>   -- POP/IMAP/SMTP Policies And Considerations
>>
>>
>> I look forward to your feedback and suggestions, but note we only have a few days left to decide on the scope, in order to to request this BOF at the Vancouver EITF meeting in March.
>>
>> 	-- Michael --
>>
>>
>> For those not informed, we are looking for a home as well to discuss our CLIENTID initiatives
>>
>> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_text=1
>> https://tools.ietf.org/html/draft-yu-imap-client-id-03
>>
>>
>>
>> -- 
>> "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.
>>
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art
> 

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