Re: [lamps] Murray Kucherawy's Discuss on draft-ietf-lamps-e2e-mail-guidance-15: (with DISCUSS and COMMENT)

[Daniel Kahn Gillmor <[e-mail]>]

Hi Murray--

A couple thoughts on some of your COMMENTs below:

On Wed 2024-03-06 23:09:31 -0800, Murray Kucherawy via Datatracker wrote:
> I'm curious: If there are no committed or planned implementations,
> what was the source for most of this advice?  Prior working groups in
> the area of email security, like DKIM and DMARC, have firmly avoided
> providing any sort of user interface advice on the basis that we
> simply do not have experience from which to develop such advice.  I'm
> wondering what's different now.

A number of cryptographic MUA implementations already do significant
parts of this work, but not all of them do everything.  The goal of
publishing this is to help MUA implementers egg each other on in
improving the state of the art.

We actually do have a fair amount of experience as users and developers
of cryptographic MUAs within the IETF, and we also have significant and
substantive published guidance and problem statements from adjacent
groups, like the EFAIL researchers (https://efail.de/), the Autocrypt
project (https://autocrypt.org/) and the nearly-annual OpenPGP e-mail
summits (https://wiki.gnupg.org/OpenPGPEmailSummits).  Much of this work
leans on and consolidates the insights developed and published by these
other groups, giving appropriate credit.

I agree that we don't have as much participation in the IETF from a few
of the big MUA implementations as i would like; but in part that may be
because we've never taken on work that feels relevant to them.

Hopefully publishing this guidance will help bring more attention to the
gaps in the ecosystem, and if other MUA implementers have additional
suggestions, or want to explore some of the territory mapped out in the
"Future Work" appendix, or even want to complain about the guidance
we've published, they'll see the IETF as a place to advance some of that
work in an interoperable, usable, and secure fashion.

> The discussion about lock icons and such was interesting.  Over on the DKIM
> list, there was some recent discussion about whether such user indications are
> useful at all, whether they highlight security or non-security of a message. 
> Some studies were cited that suggest these simply have never worked.

DKIM and DMARC are designed, as i understand it, to typically operate at
the level of a domain or server.  So it's not surprising that end-user
indicators for these features haven't worked.  they probably don't match
the end user's mental model of what is happening with e-mail.

If you mean that no security indicator has ever worked, that's a
different assertion.  Maybe even a true one, but i haven't seen research
that is quite that pessimistic.  I do know users who have found some
security indicators helpful in avoiding significant risks in some cases
(activists avoiding cracking attempts; employees defending organization
resources), but i agree that there's a question about tradeoffs with
false positives, comrehensibility, etc.

The cleanest user stories have very minimal indicators.  For example,
"If you send or receive a message on Signal Private Messenger, it will
be end-to-end encrypted" is about as good as it gets; no indicator
needed except for which app is in use!

But, maybe even more than most IETF protocols, e-mail suffers under the
Curse of the Deployed Base™, and that means we need to address what it
means when the user stories are not quite so clean.  Thinking through
the semantics of coherent security indicators is part of that work.

Seems to me we have two choices: (a) abandon the idea of using e-mail in
an end-to-end cryptographically secure manner on a 'net that is
increasingly subject to surveillance, fraud, and attack, or (b) chart a
path forward with some reasonable defenses for a widely-deployed,
interoperable, federated messaging system.

If i could be convinced that e-mail will die off completely and be
replaced by something with comparable reach that isn't beholden to a
single operator, i'd be pretty happy with (a).  Maybe the MIMI work will
get us there!  But until that happens, as a prominent custodian of the
e-mail ecosystem, i think the IETF needs to work on (b) as well.

    --dkg