ietf-smtp
[Top] [All Lists]

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

2016-03-12 08:16:55
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
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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.

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

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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>