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

From: Michael Peddemors <[email-masked]>
Date: Mon, 3 Feb 2020 13:06:23 -0800

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.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 3 Feb 2020 21:39:54 +0000

Hiya,

> "Birds of a Feather (BOF)" on email authentication security.

I'd love to see improvements in IMAP for countering
password guessing attacks from random sources. I'm
not sure how well 2FA schemes are supported in IMAP
myself but I think something like that would be good
if widely and easily deployed. TBH though, I'm very
unsure how likely it would be that such improvements
would get deployed in major clients, servers and
services but it'd be good if they were. (I was at a
meeting recently where IMAP was described by a small
mail operator as a "legacy protocol" when compared to
a proprietary one from their fav. vendor that does
support 2FA;-()

I'm also not clear that sending more long-lived
identifiers about is at all the right approach (in
particular not MAC addresses and the like!). So
even if the problem is a good BoF topic, I dunno if
the approach in draft-yu is what I'd like to see
happen. (That's based on a v. quick scan of only
that draft, sorry if I've gotten the wrong end of
the stick!)

Anyway FWIW, I'd go along to a bar BoF or formal
BoF on this topic.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 3 Feb 2020 23:44:55 +0100

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

> On 3 Feb 2020, at 22:06, Michael Peddemors <[email-masked]> wrote:
> 
> Call for Feedback:
> 
> 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.
> 
> 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.
> 
> 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
> 
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 3 Feb 2020 14:54:10 -0800

> In any case, I’m not sure a formal BoF is called for at this point.  Maybe a bar bof.

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)

---

From: Steffen Nurpmeso <[email-masked]>
Date: Tue, 04 Feb 2020 00:11:15 +0100

Eliot Lear wrote in <[email-masked]>:
 |> On 3 Feb 2020, at 22:06, Michael Peddemors <[email-masked]> \
 |> wrote:
 |> 
 |> Call for Feedback:
 |> 
 |> "Birds of a Feather (BOF)" on email authentication security.
 ...
 |> 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/enhancem\
 |> ents 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?
 ...
 |> 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_te\
 |> xt=1
 |> https://tools.ietf.org/html/draft-yu-imap-client-id-03

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

New nuto-configurations (with old software), and old dangling
configurations on user boxes, maybe.  But new clients, or users
which create new accounts manually, or users in an environment
with an active administrator, i do not know.

I would vote for keeping complexity low, especially when
unnecessary.  For example the new Unix Alpine version ships with
direct XOAUTH2 support, including credential creation and renewal,
it needs JSON and HTTP for this, i think.  This makes more
dependencies etc. etc.  I would include that in the protocol, for
example, add a renew parameter, and let that cause an
additional/extended authentication response with includes the
renewed access token.  Just as an example, the entire additional
logic, or usage of external tools (like mine needs), etc., is
gone.  Lesser configuration for the user also.

And i personally do not think adding yet more to a protocol itself
is a right thing to do, especially if the protocol is only payload
for a security layer which has the potential to provide desired
additional information.  For example, EXTERNAL authentication
(which however does not seem to be supported well by widely used
server/s).  Or passing a client certificate as part of the
authentication step, if you all enforce XOAUTH2 then this can very
well be passed as a base64 token, too.  No need for more commands
which even possibly require roundtrips, or at least more C/S
answer/response interaction.
Requiring EXTERNAL has the nice property that the secure transport
is implicit.

--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: Daniel Migault <[email-masked]>
Date: Mon, 3 Feb 2020 19:26:39 -0500

While the use case is limited to email, I am wondering if the design of an
TLS extension would be in scope, so it could be re-used by other
applications.

Yours,
Daniel

On Mon, Feb 3, 2020 at 6:11 PM Steffen Nurpmeso <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_te\
>  |> xt=1

-- 
Daniel Migault
Ericsson

---

From: Brandon Long <[email-masked]>
Date: Mon, 3 Feb 2020 18:23:14 -0800

I mean, if it's part of auth, shouldn't it be in SASL?  Michael and I have
had that argument before, but in any case, where isn't really the question
so much as whether it's useful, the details can be worked out.

It has the benefit of simplicity vs things like OAUTHBEARER, but is that
really the barrier here?

Brandon

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 04 Feb 2020 14:41:52 +0000

On just this one point:

On Tue, Feb 4, 2020, at 2:23 AM, Brandon Long wrote:
> I mean, if it's part of auth, shouldn't it be in SASL? Michael and I have had that argument before, but in any case, where isn't really the question so much as whether it's useful, the details can be worked out.

I do think that if this needs solving that it should be solved at SASL level (because it is cross protocol).

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 4 Feb 2020 07:04:12 -0800

On 2020-02-04 6:41 a.m., Alexey Melnikov wrote:
>> I mean, if it's part of auth, shouldn't it be in SASL?  Michael and I 
>> have had that argument before, but in any case, where isn't really the 
>> question so much as whether it's useful, the details can be worked out.
> 

And that's why a BOF would be a good idea ;) We strongly feel that 
CLIENTID is more than a component of SASL, as a 'trust factor', an 
'access control token', and as an element of 'two factor'.

Should an implementor choose to use CLIENTID and pass it on to the SASL, 
perfectly fine if they want to do logic there, but this makes it 
available to all forms of authentication.

But we can talk CLIENTID at the BOF, for now looking to see overall 
interest in the topic of email security, and what should be included.

	-- Michael --

---

From: Daniel Migault <[email-masked]>
Date: Tue, 4 Feb 2020 13:50:16 -0500

Hi,

I agree that my question was whether this could be useful to rely on the
lower layer (e.g. TLS) . I see two types of mechanisms:
1. Those that require interactions between the application and the TLS
layer, typically if we ask to type the password.
2. Those that can completely delegated to TLS, and just enabled them is
sufficient.

I like (1.) but my impression is that this has not been so successful so
far. So I am wondering if that is a path we should consider, and at least
try to make it successful. I am happy to hear what people think.

For (2), I am assuming that interactions between the application and the TLS
layer may add complexity, which slows adoption of these mechanisms. As a
result, it might be good to explore also extensions that provides limited
capabilities. As 2FA was mentioned, mechanisms like identity pinning [1] is
one example of a specific extension that could address partially some needs
without requiring interaction between the application and the TLS layer. I
might be biased though.

Yours,
Daniel

[1] https://www.rfc-editor.org/rfc/rfc8672.html

On Mon, Feb 3, 2020 at 9:23 PM Brandon Long <[email-masked]> wrote:

>> While the use case is limited to email, I am wondering if the design of
>> an TLS extension would be in scope, so it could be re-used by other
>> applications.
>>
>> Yours,
>> Daniel
>>

-- 
Daniel Migault
Ericsson

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 4 Feb 2020 19:53:52 +0100

On Mon 03/Feb/2020 23:54:10 +0100 Michael Peddemors wrote:
>> I would suggest that one delve a bit into per-destination preauthorization
>> and how that might work from a UX perspective.
>>
> 
> 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?

The term "identity validation security" sounds overly specific.  I'd suggest
"authentication security" tout court.  The fact is that "email authentication"
has taken on the meaning of validating the domain ownership of the sending
MTAs, see for example:

https://www.iana.org/assignments/email-auth/email-auth.xml
https://en.wikipedia.org/wiki/Email_authentication

Best
Ale
--