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

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 <steffen@sdaoden.eu> wrote:

> Eliot Lear wrote in <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>:
>  |> 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.
>  ...
>  |> 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)
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>

-- 
Daniel Migault
Ericsson