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

[Steffen Nurpmeso <[e-mail]>]

Eliot Lear wrote in <[e-mail]>:
 |> On 3 Feb 2020, at 22:06, Michael Peddemors <[e-mail]> \
 |> 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)