Subject: Re: [dispatch] [BACKGROUND] Request for Dispatch to discuss steps forward on email security issues.

From: Ben Campbell <[email-masked]>
Date: Sun, 1 Mar 2020 11:56:48 -0600

Hi Everyone,

Do any of our email experts have thoughts on Michael’s proposal and/or the drafts?

Thanks!

Ben.

> On Feb 12, 2020, at 6:18 PM, Michael Peddemors <[email-masked]> wrote:
> 
> For those that monitor other IETF lists, you may be aware that we were soliciting support for a "Birds of a Feather" surrounding issues that face the Internet today related to "Email Security".
> 
> * BEC (Business Email Compromise) are now the largest single factor in damage reported insurance claims.
> * Email Compromises lead to higher rates of Ransomware, phishing, spear
> phishing
> * Email compromise may lead theft of other resources (domain resets/transfers, banking password resets etc)
> * High number of email clients and servers that still allow transmission
> of unencrypted credentials.  Reluctance of operators to deprecate.
> * Auto Discovery Methods may preferentially try insecure methods,
>  exposing credentials
> * POP Connectors maybe inadvertently leaking credentials
> 
> Several initiatives have been pushed forward, and several discussions, however it is not yet in a form that has clear enough definitions to decide on whether the requirements for addressing this within the IETF, dictate the formation of a new working group, or a re-purposing of existing ones, or expanding their mandates.
> 
> In our case, we are pushing forward on trying to make our proposals around CLIENTID extensions to both SMTP AUTH and IMAP, and that crosses boundaries of existing working groups.
> 
> It is my contention, that there are enough topics around email security in general, that while maybe first a BOF should be formed to clarify the
> scope of such discussions, a working group be formed to solve these
> serious issues.
> 
> And while we continue to see adoption of our SMTP AUTH and IMAP CLIENTID extensions, as outlined in our RFC Drafts, we would like to see this
> become a standard, so it is more readily accepted and adopted by all email clients and servers.
> 
> This will take a working group that can encompass email security in a larger scope, than WG's only concerned with singular protocols.
> 
> Topics for Discussion -
> 
> * How/if/when should POP/IMAP/SMTPAUTH credentials being sent unencrypted be stopped?
> * Should we deprecate language in RFC's that permit unencrypted?
> * Common standards for AutoDiscovery methods for email clients
>  (No AutoDiscovery is bad as well, as it encourages insecure)
> * Advantages of using an extension to IMAP/SMTP AUTH to allow
>  for a TOKEN that can be used as part of a two factor authentication
> * Are there other authenticaton systems that would benefit as well?
> * Why CLIENTID is better as an extension to the protocol, than a SASL
>  implementation?
> 
> Some other ideas have also be floated, that is best suited to a working group with a wide enough scope to encompass these issues.
> 
> Given that we are NOT holding a BOF in Vancouver, it is suggested that we petition for time to be held in the DISPATCH session in Vancouver to discuss these things.
> 
> 	-- Michael --
> 
> PS, we can still have a BOB ('BOF over Beers') session for those who are interested.
> 
> 
> 
> 
> 
> --
> "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.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Mar 2020 10:41:01 -0500

Michael:

A digital signature on email would really go a very long way in these areas.  Of course, the hard part there is getting a certificate for use with S/MIME.  The ACME WG is working on some things that should really lower the bar on that.  Maybe we should add some energy there to get it done.

Russ

> From: Ben Campbell <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [dispatch] [BACKGROUND] Request for Dispatch to discuss steps forward on email security issues.
> Date: March 1, 2020 at 11:56:48 AM CST
> To: [email-masked] <mailto:[email-masked]>
> 
> Hi Everyone,
> 
>> On Feb 12, 2020, at 6:18 PM, Michael Peddemors <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "John Levine" <[email-masked]>
Date: 2 Mar 2020 12:47:15 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>Michael:
>
>A digital signature on email would really go a very long way in these areas.  Of course, the hard part there is getting a certificate for
>use with S/MIME.  The ACME WG is working on some things that should really lower the bar on that.  Maybe we should add some energy there to
>get it done.

We have DKIM, which has proven to scale a lot better than S/MIME.  I
don't think there's much practical difference between a DKIM signature
and an ACME S/MIME signature.  The latter can detect one user within a
domain impersonating another, but that's never been much of a problem.

In any event, I believe Mike's proposal is more about securing the
user account to make it harder for bad guys to impersonate users via
account compromise.  I'm not sure this is the right list of technical
issues but it's certainly a topic worth some attention.

R's,
John

>>> For those that monitor other IETF lists, you may be aware that we were soliciting support for a "Birds of a Feather" surrounding issues
>that face the Internet today related to "Email Security".
>>> 
>>> Several initiatives have been pushed forward, and several discussions, however it is not yet in a form that has clear enough definitions
>to decide on whether the requirements for addressing this within the IETF, dictate the formation of a new working group, or a re-purposing
>of existing ones, or expanding their mandates.
>>> 
>>> In our case, we are pushing forward on trying to make our proposals around CLIENTID extensions to both SMTP AUTH and IMAP, and that
>crosses boundaries of existing working groups.
>>> 
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Mar 2020 17:48:39 -0500

John:

> [Snip]

I would expect compromise of an account to be different than compromise of a user's private signature key.  That is why I think S/MIME signatures raise the bar.

Russ

---

From: "John R Levine" <[email-masked]>
Date: 2 Mar 2020 18:17:41 -0500

> I would expect compromise of an account to be different than compromise of a user's private signature key.  That is why I think S/MIME signatures raise the bar.

Depends.  Remember that a large fraction, perhaps a majority now, of mail 
users use webmail or phone apps managed by the mail provider.  At this 
point no major webmail provider supports S/MIME, but if they did, the key 
would be stored with the rest of the account info.

Also, dismal experience tells us that a security model that says that all 
your real mail is signed and unsigned mail isn't you creates problems, 
especially for mail sent by people as opposed to bulk or tranactional 
mail.  That's what DMARC does, and we've seen the mess it's caused.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Mar 2020 15:47:42 -0800

On Mon, Mar 2, 2020 at 3:17 PM John R Levine <[email-masked]> wrote:

> > I would expect compromise of an account to be different than compromise
> of a user's private signature key.  That is why I think S/MIME signatures
> raise the bar.
>
> point no major webmail provider supports S/MIME,

Just to clarify, Gmail as a provider does support this for enterprise and
education customers:

https://support.google.com/a/topic/9061730?hl=en&ref_topic=9061731

I realize that's likely not what John meant by "webmail provider", but it
seemed worth clarifying in case folks remembered the roll-out of the
feature to those customers.

regards,

Ted

> but if they did, the key

---

From: "John R Levine" <[email-masked]>
Date: 2 Mar 2020 18:53:01 -0500

> https://support.google.com/a/topic/9061730?hl=en&ref_topic=9061731

Oh, OK.  Also to be clear, this discussion ignores S/MIME encryption which 
is unlike anything DKIM can do.

Regards,

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Mar 2020 16:06:47 -0800

These are definitely real problems, and there have been some work on some
of it (OAUTHBEARER comes to mind), but it's probable more work can be done.

Brandon

On Wed, Feb 12, 2020 at 4:18 PM Michael Peddemors <[email-masked]>
wrote:

> For those that monitor other IETF lists, you may be aware that we were
> soliciting support for a "Birds of a Feather" surrounding issues that
> face the Internet today related to "Email Security".
>
> * Email compromise may lead theft of other resources (domain
> resets/transfers, banking password resets etc)
> Several initiatives have been pushed forward, and several discussions,
> however it is not yet in a form that has clear enough definitions to
> decide on whether the requirements for addressing this within the IETF,
> dictate the formation of a new working group, or a re-purposing of
> existing ones, or expanding their mandates.
>
> In our case, we are pushing forward on trying to make our proposals
> around CLIENTID extensions to both SMTP AUTH and IMAP, and that crosses
> boundaries of existing working groups.
>
> It is my contention, that there are enough topics around email security
> in general, that while maybe first a BOF should be formed to clarify the
> And while we continue to see adoption of our SMTP AUTH and IMAP CLIENTID
> extensions, as outlined in our RFC Drafts, we would like to see this
> This will take a working group that can encompass email security in a
> larger scope, than WG's only concerned with singular protocols.
>
> Topics for Discussion -
>
> Some other ideas have also be floated, that is best suited to a working
> group with a wide enough scope to encompass these issues.
>
> Given that we are NOT holding a BOF in Vancouver, it is suggested that
> we petition for time to be held in the DISPATCH session in Vancouver to
> discuss these things.
>
>         -- Michael --
>
> 604-682-0300 <(604)%20682-0300> Beautiful British Columbia, Canada
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Mar 2020 09:49:51 -0500

John:

> Depends.  Remember that a large fraction, perhaps a majority now, of mail users use webmail or phone apps managed by the mail provider.  At this point no major webmail provider supports S/MIME, but if they did, the key would be stored with the rest of the account info.

I am aware of at least two approaches were that is not the case, but you are correct in most approaches to S/MIME in a web mail environment.

> Also, dismal experience tells us that a security model that says that all your real mail is signed and unsigned mail isn't you creates problems, especially for mail sent by people as opposed to bulk or tranactional mail.  That's what DMARC does, and we've seen the mess it's caused.

Yes, that is a very good point.

Russ

---

From: "John R Levine" <[email-masked]>
Date: 3 Mar 2020 10:51:10 -0500

> I am aware of at least two approaches were that is not the case, but you are correct in most approaches to S/MIME in a web mail environment.

It seems to me that we need to consider scalability to non-technical users 
here.  If you and I want to exchange signed or encrypted S/MIME mail, we 
can do so easily because we know the tools and understand enough about key 
management.  If I wanted to do so with my daughter or my mother-in-law, 
both of whom use whatever mail app comes with their phone, not so much.

Regards,

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 03 Mar 2020 17:07:58 -0800

We discussed this proposal in the EXTRA WG in IETF 102 when there was a 
lot of email expertise in the room. Excerpt from minutes from EXTRA IETF 
102 (https://datatracker.ietf.org/meeting/102/agenda.html):

----
client-id: Michael Peddemors
* Proposal is a new IMAP command before authentication used to provide a
   token that is unique to the particular piece of client software, 
allowing
   some level of protection against password reuse (2.5 factor auth)
* Was generally agreed that the identified underlying issue (knowing 
that
   the same client is connecting) is worth examining.
* Would also need to be added to SUBMIT, POP3, LDAP, CalDAV, CardDAV, 
etc.
   There's already an existing draft for SUBMIT.
* The name CID is confusing because it has another meaning in MIME -
   definitely recommend renaming the command.
* Strong suggestion that SASL might be the right place for this rather
   than per-protocol commands.
* If this belongs in SASL, then it's not in scope for EXTRA and a 
different
   home should be found for the work.
* NEXT STEPS: keep discussing on extra list for now while trying to work
   out the correct home.  There is not consensus for adopting this work 
in
   its current form.
----

My opinion is this is an important problem space that merits standards 
attention and could lead to new SASL authentication mechanism(s) but I 
do not find client-id a good starting point as it's a bespoke 
protocol-specific mechanism rather than a cross-protocol mechanism.

While the OAuth SASL mechanism may work in an environment where a user 
is present with a full web browser interface, I think there's interest 
in using real two-factor to bootstrap a revokable device-specific token 
in a way that doesn't require a full web browser interface. This is 
interesting not just for mobile devices (where non-standard SASL 
mechanisms to do this have deployed), but also for IoT devices.

I think general discussion of email security is far too large a topic 
and would too easily wander into the weeds. Deployable email 
authentication mechanisms that eliminate the need to store reusable 
human passwords is a good scope limitation.

		- Chris

On 12 Feb 2020, at 16:18, Michael Peddemors wrote:

> decide on whether the requirements for addressing this within the 
> IETF, dictate the formation of a new working group, or a re-purposing 
> around CLIENTID extensions to both SMTP AUTH and IMAP, and that 
> It is my contention, that there are enough topics around email 
> security in general, that while maybe first a BOF should be formed to 
> clarify the
> And while we continue to see adoption of our SMTP AUTH and IMAP 
> CLIENTID extensions, as outlined in our RFC Drafts, we would like to 
> see this
> Some other ideas have also be floated, that is best suited to a 
> working group with a wide enough scope to encompass these issues.
>
> we petition for time to be held in the DISPATCH session in Vancouver 
> to discuss these things.
>
> 	-- Michael --
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Mar 2020 01:34:14 +0000

Hiya,

> protocol-specific mechanism rather than a cross-protocol mechanism.

I almost, but not quite, agree. 100% agree on the
problem space and importance. I'm not sure whether
SASL, despite being the obvious thing, is the right
thing.

Given how mailboxes are distributed these days, it
may be that anything that a) isn't vulnerable to
password guessing on port 143 etc., that b) could
be deployed on the major services and that c) could
be implemented by open-source MTAs... is just fine.
SASL could provide such an answer, but I'd not make
it a starting point.

Put another way - I have a (small) bunch of domains
where the IMAP listener is the only remaining vector
for password guessing and I'd really like to get rid
of that, but cannot today and maintain support for
multiple MUAs. That has to be a problem that many mail
services face, so I do hope we can try make progress
on some interoperable, deployable solution.

Cheers,
S.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Mar 2020 21:12:10 -0500

Hi Everyone,

We’ve had several people say there might be some work worth doing here, or at least related to “here”.

Do people have thoughts on the next steps for that? For example, a BoF, existing WG, new (mini) workgroup? Something else?

Thanks!

Ben.