[MlMt] Follow Up to Email Concerns

[Steven M. Bellovin]

In my opinion as someone whose primary research area, for
more than 30 years, has been security, your email credentials
are the most valuable you have. I would add that this opinion
is shared by most security professionals. Why? Because
your email account is used to reset access to almost every
other online account you have.

This doesn't mean that implementations can't be done better.
However, one constraint is that a major mail service can't
afford to have people continuously connected. A quick Google
search says that gmail has 1.8 billion users—and even with
the very large number of servers that Google has, that's too
many TCP connections. This means that most clients have
to disconnect between sessions. To be sure, it's certainly
possible, in principle, for an IMAP server to send a re-auth
token to the client to be used on the next connection attempt,
but I don't know IMAP well enough to know if that's among
the very many IMAP options even defined, let alone implemented.

On 29 Jun 2021, at 10:13, Glenn Parker wrote:

> I would be interested in a deeper discussion of the actual security 
> threats that all this awkward 2FA/OAuth2/whatever are meant to 
> address. I mean, I certainly understand the basic need for 
> authentication (and encrypted transmission) to limit access to private 
> information, but it seems like some folks are going way overboard for 
> email here. All security is a tradeoff with convenience, like a fence 
> around your property that limits free access to everyone, including 
> yourself. So, it’s important to weigh the tradeoffs.
>
> To restate my question: what are the downsides to a compromised email 
> account, and do they justify this level of access control?
>
> Users can perform a limited number of actions in the email universe: 
> read mail, delete mail, reorganize mail folders, and send mail:
>
>  * Read mail: private information could be exposed, obviously.
>
>  * Delete mail and reorganize mail folders: important (?) records or 
> progress tracking could be lost or “misplaced”. (But, seriously, 
> don’t use email for critical data storage).
>
>  * Send mail: IMHO, the biggest threat to an organization is the 
> potential for social engineering via “authentic” appearing email.
>
> I’m going to dismiss the deletion and reorganizing actions as de 
> minimus (but tell me if I’m missing something).
>
> Maintaining privacy for reading email is a valid concern, but I 
> don’t think it justifies having to authenticate on every IMAP 
> transaction.
>
> OTOH, bogus emails are potentially far more serious, and I could see 
> reasons for much tighter access when sending mail. And distinct 
> protocols controls for reading and sending could certainly be 
> implemented.
>
> I’m surprised that the level of flexibility for gating access to 
> email services seems so limited today. The crux for these matters is 
> the directory service that validates end user credentials. It seems 
> like we could implement some flexible and fairly sophisticated 
> authentication protocols (between the directory and the IMAP/SMTP 
> server) that would not require any direct tweaks to email clients. 
> This might allow, for example, a user to authenticate once via 2FA, 
> and then maintain IMAP access (using standard IMAP authentication) for 
> some number of days before having to authenticate again.
>
> It’s been a while since I worked on the software for such services, 
> so maybe there’s a lot I need to catch up on, but I basically feel 
> that “ultra-hardened” email is a poor idea.
>
> Glenn P. Parker
> glenn.parker at comcast.net
> _______________________________________________
> mailmate mailing list
> mailmate at lists.freron.com
> https://lists.freron.com/listinfo/mailmate


         —Steve Bellovin, https://www.cs.columbia.edu/~smb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20210629/2c3443c6/attachment.htm>