Subject: [Endymail] Off we go...

From: Pete Resnick <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Tue, 26 Aug 2014 15:34:37 -0700

Hi all,

We've got 88 people subscribed now, which is pretty quick for a list 
like this. Seems like there really is interest in the topic, which is good.

What we'd suggest is to start off with some sharing about what folks 
are/have-been doing in this space. We know there are a range of projects 
and proposals and it'd be good to get some information/pointers on those 
we all know about.

Its probably worth stating now that this list is *not* intended to pick 
a winner amongst those, nor to anoint one as the "official" IETF thing, 
so luckily we don't need to have a bunfight about which is the shiniest 
proposal of them all. :-)

Rather a goal of this list is to identify bits of work that the IETF 
could do to help such projects/proposals so they could achieve 
significant deployment. So if there are common bits to some 
projects/proposals that'd be interesting and especially if there'd be 
value in having those bits standardized. Or if there are other ways in 
which we could help things along that's fair game for discussion too.

And I suppose its inevitable that we'll discuss requirements and the 
real-world constraints on solutions too. And even get new and possibly 
radical proposals for how to do better in this space. And those are also 
OK and interesting for this list.

Success here will be when/if we identify some bit(s) of work that the 
IETF could credibly do that'd improve the real-world end-to-end security 
and privacy of email. And note that "credible" there requires stuff to 
be both technically sane and to have a sufficient set of capable folks 
interested and willing to do work.

When/if we do identify such, we'd probably want to start a new WG/list 
to actually do the work identified at which point this list could 
languish or continue on with more discussion of the next good thing(s) 
to do.

So off we go... What projects are folks working on, and what should the 
IETF be doing in this space?

Cheers,
Pete & Stephen

---

From: Tom Ritter <[email-masked]>
Date: Tue, 26 Aug 2014 21:20:25 -0500

On 26 August 2014 17:34, Pete Resnick <[email-masked]> wrote:
> So off we go... What projects are folks working on

Prior to Snowden's revelations, a friend and I had given some
thought[0] to a system that supported provider-to-provider encryption,
where the end could be extended on either side to end-to-provider or
end-to-end encryption.  Along the way we thought about distributing
keys over HTTPS vs DNS[1], authenticity[2], a report-only deployment
mode[3], and other stuff.  We shelved our proposal, but published our
thoughts in a document that we hoped would add some thoughts and
context to future discussions.  Full spec is at
https://github.com/tomrittervg/uee

I can't claim to be working on this, but I'm excited about
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

I'm also tangentially involved (through my job) with NCC Group's
.trust initiative[4].  There are a lot of policy controls, but also
technical ones. Some of the guarantees you will have when
communicating with a domain in the .trust gTLD will be that the domain
will have valid TLS certificates for StartTLS, will have StartTLS
available, will use DNSSEC, DKIM, and a host of other technical
requirements.

-tom

[0] https://ritter.vg/blog-uee_email_encryption.html
[1] https://github.com/tomrittervg/uee/blob/master/appendix-key-distro-choice.md
[2] https://github.com/tomrittervg/uee/blob/master/proposal.md#key-authenticity
[3] https://github.com/tomrittervg/uee/blob/master/proposal.md#report-only-mode
[4] https://www.nccgroup.com/media/112014/trust-faq.pdf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Aug 2014 22:23:02 -0400

On Tue, Aug 26, 2014 at 6:34 PM, Pete Resnick <[email-masked]> wrote:
> Hi all,
>
> We've got 88 people subscribed now, which is pretty quick for a list like
> this. Seems like there really is interest in the topic, which is good.
>
> are/have-been doing in this space. We know there are a range of projects and
> proposals and it'd be good to get some information/pointers on those we all
> know about.

My work is described on the PrismProof.org web site.

I have been looking at the reasons people don't use end to end
encrypted mail. I see the following problems:

1) Every system currently available has chronic usability problems.
They are too difficult to configure and too much hassle to use. This
is true of both S/MIME and PGP.

2) The standards battle between PGP and S/MIME has run into a
stalemate with no victor.

3) The CA trust model does not really deliver value for end entity
certificates unless the certificates are being issued by an LRA that
knows the key holder. The Web of Trust model does not scale due to the
Moore bound.

To illustrate just how unnecessarily hard it is to send S/MIME mail
today, this is what it takes to install a certificate in Thunderbird
on Windows.

1) Discover that the feature exists
2) Select a CA to issue the certificate, Comodo offers free certs but
you will only find them if you are looking for them.
3) Fill in a Web form to apply for the certificate
4) Respond to the email challenge
5) Install the certificate into the Windows keystore using the Web
browser but this will only work if you use the same Web browser as you
used to apply for the certificate
6) Export the certificate from the Windows store
7) Import the certificate into the Thunderbird cert store which is not
the same as the firefox one
8) Configure Thunderbird to use the certificate
9) Repeat this whole process every 12 months

And before you start off telling me about PGP, getting that to work
proved so tedious I gave up. The problem was that the client I tried
to use was from the 'mushroom' school of usability and does not tell
the user anything they need to know to use PGP. Not even their
fingerprint and not the key server they use either. And it insisted on
encrypting the key under a strong passphrase which is idiotic, it
should use the machine trust store.

I also have an existence proof for a solution to the usability problem.

The PPE key manager generates a personal PKI hierarchy and configures
Windows Live Mail to use it without any user intervention at all.
There are some things that I would like the user to be able to select
such as the choice of a service provider to gateway their key to other
forms of PKI.

Strong email addresses are conceptually just a PGP fingerprint bolted
onto the front of a regular email address. So we now have one
identifier that specifies the address to sent the message and the
means to validate the security policy under which it is sent. This
effectively enables the use of the de-facto PGP trust model of key
fingerprints in the S/MIME world.

The reason I am basing my work on S/MIME is that that is the standard
supported by all the mail clients. So building on that gives access to
a vast base of installed software. All we need to do is to write easy
to use tools to configure them. Or alternatively shame the providers
into fixing the absolutely dreadful usability of their current
product.

Lets get one thing straight, you don't need to have a usability lab to
spot these usability problems.

> Its probably worth stating now that this list is *not* intended to pick a
> winner amongst those, nor to anoint one as the "official" IETF thing, so
> luckily we don't need to have a bunfight about which is the shiniest

I disagree. I think the problem divides into two parts, how you decide
which key to use and how to apply that key to a message.

The first part is the area where I don't want to come to one agreement
because there isn't one single trust model that works for every
application. It is a research area where we can do some really
interesting things. This is the place where I think Certificate
Transparency like concepts really do pay off.

But innovating in the key selection space should not require people to
develop their own message format or embed it in MIME. We already have
that problem solved and deployed: S/MIME works great as a message
format and it has decades of testing in the deployed email
infrastructure and every email vendor makes sure that they don't break
it.

The biggest cost to me as a researcher in the key selection space is
having to 'enable' all those email clients. Which is why I want to
separate out the code into two parts

1) A Common core that goes in the client that has web services sockets
to talk to key services in the cloud
2) Key services in the cloud that do 'the interesting stuff'.

This is not going to be end to end security as people think of it on
day one. But this separation allows us to tweek the trust models and
update them without having to roll out new generations of email
clients. We only embed the trust model into the client endpoints after
it is proven to work.

> Success here will be when/if we identify some bit(s) of work that the IETF
> could credibly do that'd improve the real-world end-to-end security and
> privacy of email. And note that "credible" there requires stuff to be both
> technically sane and to have a sufficient set of capable folks interested
> and willing to do work.

Defining a common platform on which we can build new trust models
would be one of those bits of work:

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 27 Aug 2014 15:25:59 +0000

For distributing keys, POSH seems like it would be also be interesting:

http://tools.ietf.org/html/draft-ietf-xmpp-posh-01

As does RFC 7033 (WebFinger), both of which rely on extending trust from 
HTTPS to other domains.

On 8/27/14, 2:20 AM, "Tom Ritter" <[email-masked]> wrote:

>[1] 
>https://github.com/tomrittervg/uee/blob/master/appendix-key-distro-choice.
>md
>[2] 
>https://github.com/tomrittervg/uee/blob/master/proposal.md#key-authenticit
>y
>[3] 
>https://github.com/tomrittervg/uee/blob/master/proposal.md#report-only-mod
>e
>_______________________________________________
>Endymail mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/endymail
>

-- 
Joe Hildebrand

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 Aug 2014 15:58:42 +0000

On Tue, Aug 26, 2014 at 03:34:37PM -0700, Pete Resnick wrote:

> So off we go... What projects are folks working on, and what should the IETF
> be doing in this space?

If we get the email backbone broadly protected with TLS, the greatest
remaining risk is data at rest (messages delivered to the user's
mailbox).

For me, the first step towards protecting messages at rest, is to
encrypt them on delivery to the message store, where key management
is simplest, because that store only needs the public keys of the
recipient.

So I'd like to see support for delivery-time encryption in LMTP
servers (dovecot, ...).  This gets the recipient's mail protected
in storage regardless of the payload encryption capabilities of
the sender.  Yes, this is not an end-to-end mechanism, and it may
be too late if at some point en-route the message was transmitted
in the clear.

Such support can gradually be moved closer to the edge, with payload
encryption at the inbound gateway (roughly as far as many enterprises
can allow it, since otherwise they lose visibility into the message
content for anti-virus, data-leakage, regulatory archiving, ...).

Beyond inbound gateway encryption, there is also an opportunity
for gateway-to-gateway message encryption, but frankly I don't
see much reason to do that rather than TLS.

Finally, there is an opportunity to have end-to-end payload
encryption, but seemingly at the cost of many of the features
for which users trade-in their privacy with the major consumer
email providers.  Server-side anti-spam and search for example.

With today's technologies we know that "Johnny can't encrypt", if
we improve the technology, what will it take for "Johnny" to be
willing to encrypt?

What's the sweet-spot for protection of messages at rest that does
not unacceptably impact usability?  Unlike IM conversations, that
users expect to be largely ephemeral, people tend to "hoard" email
as a long-term record of communication.

So with each technology or design discussed on this list, perhaps
it might be helpful to understand where it fits into the protection
spectrum and what are the usability trade-offs and the target
audience.

My take, is that with mobile devices and the like, which do not
attempt to maintain a complete locally searchable archive of email
(as one might with IMAP on a dedicated personal computer) there is
strong incentive for email content management at the server, and
end-to-end just can't compete.  The usability constraints may be
far too tight.

I don't use any of the major providers for email, and don't
synchronize smart-phones and the like to my self-hosted IMAP mailbox.
So I can work with the quite decent search and anti-spam capabilities
in the desktop/laptop IMAP client.  I am very much the exception
to the rule.  

So I am somewhat skeptical that the competing demands in this space
can be met simultaneously, and my guess is that usability will win
hands down for most users.  It would be nice for my hunch to be
proved wrong.

-- 
	Viktor.

---

From: Michael Kjörling <[email-masked]>
Date: Wed, 27 Aug 2014 17:02:40 +0000

> as a long-term record of communication.

On the reverse side of the generally small, stamped, disk-shaped
metallic object to which we ascribe monetary value, otherwise known as
a coin, these to me both sound like implementation concerns.

There would be little stopping me from, today, taking an appropriate
library and adding it to the LMTP delivery chain code of my favorite
software. I could even almost certainly do something like the first
basically by chaining together procmail and gnupg/openssl/whatever on
the LMTP server and end user client side. Presto, email security at
rest server-side. No IETF work needed. With a few relatively simple
modifications, it should be possible to make the software guarantee
that (as far as the OS can guarantee it) a message never leaves server
RAM unencrypted. (We already have POP3 and IMAP4 over both SSL and
STARTTLS; it should be a relatively trivial change allowing encrypted
at rest messages to not be downloaded over an insecure connection.)

UAs can cache decryption keys for whatever period of time is deemed
reasonable, and the length of that period of time (and the allowed use
of cached keys without reauthentication) can be made configurable by
the user likely without overwhelming even relatively new users.
("Allow searching secure email without requiring a password" and
"Allow displaying secure email without requiring a password" could be
a start.) It wouldn't be perfect; for example, someone with a debugger
running on the system in question would be able to gain access to the
decryption keys; but then again at that point it's quite possible that
the user's system is rooted anyway, in which case transport security
doesn't help. (That needs quite different steps to mitigate, which
would seem to me to be outside of the scope of this discussion list.)

An issue that any end-to-end message encryption scheme would more or
less have to address, though, as I see it, is _how do I know that I am
encrypting to the right individual?_ Yes, computers could take care of
that part, especially once communications is established, but somehow
Alice still needs to know that she is sending that first message (and
encrypting it to) Bob Bravo, who uses [email-masked] because Mallory
snatched [email-masked]. Considering that e-mail address mistypes are
quite common in the wild, and may very well result in the message
actually being delivered to the wrong person, initial establishment of
secure communications seems like something that would need addressing
(figuratively _and_ literally).

-- 
Michael Kjörling • https://michael.kjorling.se • [email-masked]
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 16:57:25 -0400

Hi Phillip,

--On August 26, 2014 at 10:23:02 PM -0400 Phillip Hallam-Baker 
<[email-masked]> wrote:

> proved so tedious I gave up

Right, but some major players are getting onboard with OpenPGP, as per 
<http://www.pcworld.com/article/2462852/yahoo-mail-to-support-end-to-end-pgp-encryption-by-2015.html>. 
So one would hope they will tackle usability given the broad scope of their 
user base.

-- 
Cyrus Daboo

---

From: Frank Li <[email-masked]>
Date: Thu, 28 Aug 2014 14:42:40 -0700

(Unrelated to previous discussion)

Food for thought:

One thought I had a while back was the merits of hash-based email
addressing, where the address is a relatively short hash of an account's
public key (just like PGP fingerprints). The idea was that the email
address itself can validate the PK, and the PK can be automatically
retrieved from anywhere (key servers, mail provider). This could allow a
mail client to completely transparently handle key management and email
encryption/decryption/signing.

While the email address is non-human-sensible, the mail client can provide
local user-chosen bindings, similar to how a contact book on a phone maps a
name to phone #s. Certainly there are other usability challenges as well
though. Perhaps proper user interfaces can make dealing w/ a hash-address
not too much of a burden.

Ultimately this is not really different from PGP; we're merging an email
address and fingerprint in PGP into a single "hash-based" email. But the
idea was that in this scheme people would only conceptually deal w/ an
email address (granted non-sensible). They don't need to be aware of keys,
fingerprints, or web of trust, which might help usability. Certainly the
idea has issues though, food for thought.

On Thu, Aug 28, 2014 at 1:57 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi Phillip,
>
>
> --On August 26, 2014 at 10:23:02 PM -0400 Phillip Hallam-Baker <
> [email-masked]> wrote:
>
> Right, but some major players are getting onboard with OpenPGP, as per <
> http://www.pcworld.com/article/2462852/yahoo-mail-to-
> support-end-to-end-pgp-encryption-by-2015.html>. So one would hope they
> will tackle usability given the broad scope of their user base.
>
> --
> Cyrus Daboo
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Aug 2014 17:44:09 -0400

> So one would hope they will tackle usability given the broad scope of their

So far I don't see a supported product from either.

The problem with usability is that there is a naive version which
amounts to 'hide all the cruft from the user so they don't notice'. In
furniture terms this is like sticking veneer over everything so people
don't notice its made from chipboard. Calling chipboard engineered
wood doesn't change things either.

To make either PGP or S/MIME usable we need to address the structural
issues that are making it hard to use. In particular:

* Easy way to migrate encryption keys into new devices.

* Key recovery mechanisms so people don't loose their mail by accident.

* Easy key rollover

These are not hard to do if they are considered problems that have to
be solved. But what has happened in the past is that they have been
shuffled under the mat as 'advanced user problems'.

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 28 Aug 2014 23:04:45 +0100

On Thu, Aug 28, 2014 at 02:42:40PM -0700, Frank Li wrote:

[...]

> though. 

We are still at a point in time where people need to write down
e-mail addresses with a pen or pencil for later transcription, or
spell them out loud.  Unless we can come up with something that is
typo-proof, I think that usage will be problematic.