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

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

On Mon, Feb 3, 2020 at 4:27 PM Daniel Migault <mglt.ietf@gmail.com> 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
>
> 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
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>