Subject: Re: [pkix] [ietf-smtp] e2e email security (Was: Re: another attempt to canonicalize local parts)

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2016 15:26:17 +0000

>> For example, issues not raised so far include: there is little
>> or no MUA development these days;

Outlook is the only desktop MUA I know of that gets significant 
development, and the changes are mostly for non-mail stuff.  Thunderbird 
was declared dead, but still gets regular updates.  It is my impression 
the updates are mostly due to the large amount of code it shares with 
Firefox.

On the other hand, there is tons of MUA development for mobile devices. 
Look in the Apple and Google app stores and you will find hundreds of mail 
clients.  Many claim to support S/MIME and PGP; I haven't looked to see 
how usable they are.

> The really BIG players are, possibly with an exception or two, also 
> pushing Webmail rather than MUAs on the user devices.

I think the cause and effect are reversed here.  Hotmail, Yahoo, Gmail, 
and AOL all have perfectly functional IMAP and submission servers, and I 
have them all set up in alpine.  Nonetheless, you are correct that 
everyone uses webmail because it requires no extra setup, works on all of 
their computers, and due to the rapid improvment of web browsers in the 
past decade, webmail has if anything better UI features than separate 
MUAs.  Before we put a lot of effort into MUA crypto we might want to 
revisit MUA configuration and whatever else makes them painful to set up 
and use.

R's,
John

PS:
>
> Yes.  I note that a proposal or two were made long ago to move
> toward a three-layer envelope (transport information, trace
> information, and the rest of the current headers) rather than
> todays two-layer (transport and and current headers including
> trace info) went absolutely nowhere.

As I recall Ned gave us a strong hint that has patent problems.

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Mar 2016 09:16:00 -0500

Stephen,

I generally agree with your overall summary of the general
problem, but with a few observations inline below. 

--On Saturday, March 12, 2016 11:30 +0000 Stephen Farrell
<[email-masked]> wrote:

>...
> I think the subject has wandered and wanted to try to up level
> this a bit to see if there's interest in tackling the general
> problem...

> On 12/03/16 09:46, John R Levine wrote:
>> This confirms your point and John K's that current MUA
>> crypto is for the most part a checklist item, not something
>> that most people would want to use.
> 
> Yep, I think that's very true sadly, esp. for SMIME. A little
> less so for PGP maybe, but both are IMO failures.

Less so only because PGP isn't on the checklist and is generally
available as add-ons or plug-ins of various flavors, so anyone
who wants it has to take action.  On the other hand, what is
available for PGP is often of very poor quality and utility,
typically because the right hooks are not available for the
add-ons to which to attach.  Certainly I agree with the
"failure" part and note how frequently users of PGP still see
the old ASCII-armored form, including from me.

> (As were PEM and MOSS before them.)
> 
> Even more sadly, I think the issues raised in this thread are
> only a subset of the problems that need fixing if we are to
> see ubiquitous use of e2e email security.
> 

The summary below is based on my knowledge.  If I've missed
anything of importance that is available more or less globally,
I'd appreciate it if someone would tell me.

I don't know if meant MUA deployment generally or MUA deployment
with PGP and/or S/MIME support built-in, but, depending on how
one counts, even the first is true.   With one price point set
by FOSS products that are not exceptionally well-maintained for
some of the IMAP and other capabilities that make desktop MUAs
most attractive and another set by products that are bundled
with integrated business desktop (aka "office") products and
therefore "free", there has been no money in the desktop MUA
business for years.  That, in turn, discourages development of
well-designed MUAs for handhelds that work well with those
desktop features, etc.

This is going to be a difficult hole to dig our way out of.  The
observation that the firm that took over the commercial PGP
product has apparently concluded that it is worth supporting/
selling only to large enterprises and bundled with other
functions on an annual, per-endpoint, "service" basis, making
the price for a typical individual or very small business with
multiple devices (desktop, tablet, handheld, laptop,...) very
high.  Whether it is a good strategy for them or not, it helps
reinforce the message that, if e2e email security is good for
anything or anyone, it is only for intra-enterprise use in large
enterprises.

> both PGP and S/MIME were
> really designed to only consider that the user has one MUA,
> which is no longer true - fixing that requires new
> infrastructure (to move or access private keys) which we've
> failed to do well at least once;

I'm not sure I completely believe the "designed for" part, but
the conclusion is certainly correct.

> the email environment now is
> very centralised compared to when PGP and S/MIME were
> designed, with the result that unless enough of the really BIG
> players play, any proposal is dead, and maybe the BIG service
> providers aren't incented to improve the overall ecosystem and
> are more likely to want to improve things for their own users;

The really BIG players are, possibly with an exception or two,
also pushing Webmail rather than MUAs on the user devices.  In
at least a subset of those cases, they have a business
motivation for that preference -- it keeps eyeballs on their
sites and facilitates selling advertising.  Some have interfaces
that are more or less IMAP-friendly than others, but support
tends to be not very good or not easily accessed.    I've also
heard speculation that a big email provider who seemed to be
making guarantees about really strong security would incur, or
at least risk being tied up in litigation about, liability if
that security failed to protect critical information.

> Mail header fields are not protected which won't meet user
> expectations and protecting those will cause a major tussle
> with anti-spam;

Yes.  I note that a proposal or two were made long ago to move
toward a three-layer envelope (transport information, trace
information, and the rest of the current headers) rather than
todays two-layer (transport and and current headers including
trace info) went absolutely nowhere.  That approach would
address at least part of the anti-spam problem but would still
leave sender and recipient information exposed.  Hiding/
securing that information at both the SMTP and IP layers
probably requires increased centralization of providers, and
that, I hope obviously, has its own problems, including security
ones.

>  and lastly for now, e2e email security if
> widely deployed will force us to change where we locate
> anti-spam and similar technologies.

That may or may not be part of the centralization/ aggregation
problem.  On the other hand, I'm on record as believing that
most of our present anti-spam tactics are a dead end that shift
the problems onto those (individuals and countries) with fewer
resources, and that is socially as well as technically
undesirable.

> And all of the above (plus the other issues already raised) are
> each individually and independently killer arguments. So I'm
> not hopeful frankly.
 
> That said, I do think we should be encouraging folks who are
> willing to try to move the needle, via experiments or
> otherwise. And we should be liberal in judging those
> experiments, since another conclusion I've reached after
> considering the above issues is that if we ever do manage to
> get e2e working well and deployed, then the technology we'll
> end up using will be radically different from S/MIME or PGP
> (though it may well have lineage from both). So even weird and
> wonderful experiments that involve interoperability breakage
> should be encouraged IMO, assuming they are sane.

I actually agree.  I have always been in favor of performing
these experiments.  My concern is that those experiments be
_extremely_ clear about known risks and, mostly as a result,
either who should be carrying them out or what issues have been
identified going into the experiment.  Taking the DANE OpenPGP
spec as an example, I think it is appropriate, even necessary,
that there be an open and sincere discussion with the email
community, especially those with significant deployment and
operational experience, about possible risks and ways to
mitigate them and a similar discussion with the DNS operations
community about the tradeoffs between storing keys in the DNS
and storing pointers to keys (and perhaps fingerprints) in the
DNS but the actual key data elsewhere.  Again, if the conclusion
is that there are significant operational risks (especially if
the experiment is successful in getting a lot of use/testers)
then the IETF community needs to consider those risks and
whether the experiment is likely enough to be productive to
justify them.  In any event, the results of those discussions
should make it into the documents in a clear and balanced way
even if the experiment itself is not changed.  

> We did btw, start a mailing list for this discussion a while
> back. [1] That that didn't seem to get traction also seems to
> re-enforce the impression that we're not yet in a place where
> we'll be able to make significant progress on the overall here.
> (Again, leading us back to encouraging experiments.)

I did look at the archive of that list in the process of writing
my note about your "resolution" message and decision and noted
that there were a very small number of messages, the most recent
in December.  So, to the extent to which that list is relevant,
I agree with your "no traction" and "not yet in a place..."
conclusions.

best,
     john