Re: [cap-talk] [friam] and so it goes

[Jed Donnelley]

On 1/8/2016 3:23 PM, Raoul Duke wrote:

https://news.ycombinator.com/item?id=10867647

This topic of secure email is something that I feel frustrated to bursting about (from the above):

"email is not authenticated with GPG: it is a usability nightmare. Even many technically apt people find it too much of a headache.":

This seems so counter intuitive to me that I'm driven toward a "big brother" conspiracy model.

Here's how simple I believe it should be:

1.  Every time I install an email agent it generates a new random public/private key pair for my use by this agent.

2.  Every time I send an email the public key for my current agent install is sent along.

3.  Any time I receive an email from somebody whose agent sent their currently used private key along (as all good agents should with EVERY email), my agent will default to sending any new messages to that 'from' address (e.g. the initial reply any any new messages to that "from" address) with an encrypted and signed message using my private key and their public key - sending my public key along also of course as always in a header field.

With this approach EVERY message EXCEPT a first introductory message is transmitted encrypted and signed so that I have some crypto identification of the sender - at least to strongly match their client install.

IMO the whole business of "web of trust" is way (!) overblown.  With this approach public/private key pairs are "disposable", much like how ssh keys are commonly used.

There are some tools to help with "web of trust" stuff that would be useful with the above approach.  Of course my client must (one of the few agent requirements with this protocol) keep a table matching email "from" addresses with public keys.  If I ever receive a message "from" some email address that comes with a changed public key, I would like to be notified of that fact.  It may simply be that the sender has installed a new email agent or generated a new key pair out of concern that an older private key was compromised.  It might be that something is trying to spoof sending email from a contact who I had previously identified by a public key.  Generally this isn't a big deal in either case.  In most cases I'd simply accept the new key - much like when dealing with ssh keys.

It might be helpful for my client to allow me to associated multiple public keys with a given "person".  Again I don't consider this a big deal.

I think it might be illustrative to show how, once the above approach is established, people could set up a tighter identities ("web of trust") if needed.  For example, suppose we have the above setup and I want to set up securely identified email communication with a financial or legal adviser who I otherwise interact with through a secure login to a web site (think Fidelity or Etrade or a bank or whatever).  There are many ways to set up such secure communication.  A simple one would be for the web site to display a public key for my agent and for me to submit my (current) public key to be trusted for such communication through the web site.  No muss, no fuss.  I'm sure there are even easier ways (along the lines of emails with web links that are commonly used) that would avoid exposing the notion of a "public key" (perish the thought).

There are many ways to set up stronger notions of trust associated with a given public key, bind such keys together, transit from one key to another, etc.  There might be some helpful tools in clients to support such mechanisms, but even without any such support I believe we would be way, way "ahead" of where we are now in terms of secure email.

Of course I can also imagine ways to "spoof" identities with such a scheme as well as the next person.  In most cases (e.g. as with current email) I just don't care that much about identities.  In the few cases when I do (e.g. financial or legal transactions) care must be taken.  I feel confident that protocols and support tools could support such situations.

I'd be interested to hear others criticize the above approach to secure email.  I can understand how the intelligence agencies might shake in their boots at the thought that such a scheme (default strongly encrypted email) might become widespread. However, for the rest of us, what might anybody see as a downside to the above approach?

--Jed  http://www.webstart.com/jed/

[David Nicol]

As people in the comments at the ycombinator item id note, the problem
is social rather then
technological. I've been using e-mail long enough to remember when a
good portion of the traffic on lists such as this one would have PGP
signature blocks, and when

https://en.wikipedia.org/wiki/Geek_Code

was a brilliant parody of them, which fact is somehow absent from the
wikipedia article on Geek Code.

On Sun, Jan 17, 2016 at 2:35 PM, Jed Donnelley <capab...@webstart.com> wrote:
> On 1/8/2016 3:23 PM, Raoul Duke wrote:
>
> https://news.ycombinator.com/item?id=10867647
>
>
> This topic of secure email is something that I feel frustrated to bursting
> about (from the above):
>
> "email is not authenticated with GPG: it is a usability nightmare. Even many
> technically apt people find it too much of a headache.":
>
> This seems so counter intuitive to me that I'm driven toward a "big brother"
> conspiracy model.
>
> Here's how simple I believe it should be:

_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

[Jed Donnelley]

On 1/17/2016 9:25 PM, David Nicol wrote:

As people in the comments at the ycombinator item id note, the problem
is social rather then technological.

Thanks for the note David,

I'd very much like to better understand any of the social aspects of 'the problem' - which I take to be that of getting to default encrypted and signed email.  I read through the comments on the ycombinator page.  I agree that setting up and using GPG encryption as implemented in current email clients (at least my experience with Thunderbird) is a very painful process.  I've also had experiences like:

"I just stopped doing this, because the only tangible impact was people asking why my emails had weird incomprehensible junk in them. Admittedly this usually took the form of mild derision rather than outright hostility."

This is why I suggested an implementation change in email clients that would make such encryption and signing:  1. happen by default and 2.  be invisible.  In that case there would be never be any "weird incomprehensible junk" seen in emails.  I hope you agree that if the implementation is automatic and invisible then a situation like this, "Three hours later I hadn't gotten it working and gave up." doesn't arise.  With this approach there is nothing to get working.  If there are other social problems that would still be there I very much want to learn about them before pursuing this topic further, so I appreciate any thoughts on the matter.

Even in the unusual case where a user changes their email client (e.g. with a reinstall) or otherwise changes their public/private key pair AND then receives an email from a contact before sending a new email to that contact, the email client could be coded to automatically reply with a "changed key" message to the sending client.  This then turns into the case where a contact sends a message from an email address that was formerly associated with a different public key.  As noted, I personally would like to be notified of such a change so I can probe to figure out what's going on, but people could ignore such notifications if they wished.  In that case neither user would be aware of the key change.  Sure, in that case a user would be subject to a man in the middle 'attack' where such a middle man could pose as a previously known end user.  That can be important in the 1% of cases where it's vital that a person or institution is bound to a message exchange.  In those few cases people would have to be cognizant of such key changes and go through another binding handshake.  In the other 99% of cases I don't really care if I'm communicating securely to a man in the middle instead of some other entity known without any binding at the other end of an email address.

When those very few situations do arise where it's important to have encrypted and signed emails that ARE bound to a person or institution, all the infrastructure would be in place and 'all' one need do is the binding.  As I noted, I believe this binding can be done quite easily, for example just by leveraging off of a secured web interface in many cases.  None of the tedious aspects typically associated with developing a "web of trust" (been there, done that) are needed for encrypted and signed email that is as good as public key encryption technology can support.  I don't believe that this situation is any more problematic than the learning that people have to go through to appreciate the value of "https://..." in Web URLs.  Anybody who cares in the least could notice key changes and either clarify how they happened or in any case do a new binding with the new key.

Thanks for any time to respond with anything that might help me to understand other social problems that I'm missing.

Sincerely,

James E. (Jed) Donnelley  http://www.webstart.com/jed

<the rest is historical>

[Tristan Slominski]

The approach you describe sounds familiar to what Apple does with iMessage: http://techcrunch.com/2014/02/27/apple-explains-exactly-how-secure-imessage-really-is

The social problem seems to not be an issue for them. The difference between the systems appears to be that there is no central point of control over email clients to roll out a switch and that there is no central point of trust for email clients to agree on.

The transition from insecure system to a secure one seems to be the crux of the problem to me. That's what results in "why are you sending me this junk" experiences.

[Daira Hopwood]

On 18/01/16 05:25, David Nicol wrote:
> As people in the comments at the ycombinator item id note, the problem
> is social rather then
> technological. I've been using e-mail long enough to remember when a
> good portion of the traffic on lists such as this one would have PGP

> signature blocks [...]

Indeed. PGP is not an example of users being too quick to dismiss a
security technology due to lack of usability. It is an example of a system
persistently failing to improve its usability, even given a decade of
breathing room by a user community who were actively willing its
developers to address those issues.

--
Daira Hopwood ⚧Ⓐ

[Sandro Magi]

Certainly a marked improvement over unencrypted content, but it doesn't handle key expiry. Once my key expires, all my subsequent e-mails to you will not match the public key you stored, so what's a key update protocol that's also secure?

Encrypted messages also reduces the effectiveness of search, which is a big issue with today's e-mail volume.

Sandro

[Tony Arcieri]

On Mon, Jan 18, 2016 at 1:02 AM, Jed Donnelley <capab...@webstart.com> wrote:

This is why I suggested an implementation change in email clients that would make such encryption and signing:  1. happen by default and 2.  be invisible.  In that case there would be never be any "weird incomprehensible junk" seen in emails.  I hope you agree that if the implementation is automatic and invisible then a situation like this, "Three hours later I hadn't gotten it working and gave up." doesn't arise.  With this approach there is nothing to get working.  If there are other social problems that would still be there I very much want to learn about them before pursuing this topic further, so I appreciate any thoughts on the matter.

So for what it's worth, this is already happening server-side with SPF, DKIM, and DMARC, just not in an end-to-end manner. Any emails coming from me, for example, are DMARC authenticated by Google. This is happening in a totally transparent manner without any additional "gunk" added to message bodies (only to the headers).

 

In that case neither user would be aware of the key change.  Sure, in that case a user would be subject to a man in the middle 'attack' where such a middle man could pose as a previously known end user.  That can be important in the 1% of cases where it's vital that a person or institution is bound to a message exchange. 

A system where any remote attacker can arbitrarily change authentication keys without notifying the user doesn't sound like it offers any security at all.

There are systems that try to manage keys on a user's behalf, like CONIKS:

http://www.coniks.org/our-solution/

In a system like this, a user authenticates to their provider and publishes a new key in their provider's CONIKS key directory. This directory maintains an append-only log of all key changes ala a Certificate Transparency log (authenticated as a Merkle log proof).

The key directory can be kept "honest" by auditor nodes which watch the directories looking for inconsistencies (and having clients check with auditors before using a particular directory's keys), and/or by clients gossiping Merkle roots to each other.

--

Tony Arcieri

[Jed Donnelley]

On 1/18/2016 8:57 AM, Sandro Magi wrote:
> Certainly a marked improvement over unencrypted content, but it doesn't handle
> key expiry. Once my key expires, all my subsequent e-mails to you will not match
> the public key you stored, so what's a key update protocol that's also secure?

Thanks for the comments. When your key expires (e.g. you reinstall
your software or even a timeout), if you send "me" an email my client
will recognize the new public key from a recognized "from" address,
notify me (if I care), and save the new key.
If I care about the notification I can do whatever I wish to reestablish
trust with the sender with the new key. In the rare but important (e.g.
legal or financial) case where a key is bound to a person or institution
then a new key binding must be done (see below for details).

If your key expires and 'I' send you a message before you send me one
then your client will respond with a "key change" message (rather than
displaying the distracting cypher text) - resulting in the situation above.

Since I mentioned "key binding" above I may as well restate a simple
protocol that I believe can leverage a secure web site login (common for
financial/legal sites) to establish a key binding for secure email. I
login to my web site and submit my email address and its associated
public key to a form. The web site binds that public key to the email
address. Thereafter any email signed by my private key can be assumed
to be from me - until my key expires, when I need to do a rebinding.
Anybody see any problem with that protocol?

For typical email use, however, I don't consider key binding a
significant issue. I'd be quite comfortable just accepting a new key
binding from anybody sending email to me in nearly all circumstances.
Even if I do so without any check or exchange I'm better off than I am
now as at least ALL messages will be encrypted and signed - even if the
sender isn't necessarily bound to a specific person or institution.
Having been notified of and accepted a new key binding to an email
address, I might be on somewhat more alert about a potential man in the
middle attack, but how often do I care? I certainly don't have any
support for caring now. If I did care in future I could do key binding
more generally (e.g. testing via alternative communication such as
telephone, video chat, or whatever). As I say, I really don't see key
binding as a practical problem except for very rare cases where
something like the key binding through a secure web login (as above)
seems perfectly adequate to me.

> Encrypted messages also reduces the effectiveness of search, which is a big
> issue with today's e-mail volume.

Are you referring to searching my own email archive? In that case why
can't it just be the clear text that is saved and searched?

If you are referring to some other email being searched, please clarify
why one would need to "search" encrypted email.

--Jed

[Alan Karp]

One way to handle key rollover is to start with two keys with different expiration dates, k1 and k2.  Before k1 expires, you generate k3 and certify it using k2.  Use k2 as your primary and k3 as secondary.  Lather rinse repeat.  This approach does not cover the case of a k2 being compromised, but its private key can be kept offline until

--------------
Alan Karp

[Sandro Magi]

On 18/01/2016 4:56 PM, Jed Donnelley wrote:
> For typical email use, however, I don't consider key binding a
> significant issue. I'd be quite comfortable just accepting a new key
> binding from anybody sending email to me in nearly all circumstances.
> Even if I do so without any check or exchange I'm better off than I am
> now as at least ALL messages will be encrypted and signed - even if
> the sender isn't necessarily bound to a specific person or institution.

What use would such silent upgrade have over current unencrypted use? I
can just spoof your friend's address passing along a new key, and start
a whole new conversation with you without you being any wiser.

The problem with such partial solutions is that they add only a thin
veneer of easily bypassed security whose deficiencies we'll have to live
with for another 40 years until the next accidental evolution. I think a
proper secure key upgrade is necessary for a solution we won't someday
regret.

> Are you referring to searching my own email archive? In that case why
> can't it just be the clear text that is saved and searched?

You certainly could, but it eliminates the possibility of e-mail as a
third-party service. Unless you think that your e-mail be stored
unencrypted on these third-party servers as well.

Sandro

[Sandro Magi]

I think your simple alternating protocol could work. Each exchanged message then shares both public keys, so both get stored to bootstrap the protocol. This can also enable secure third-party introductions, ie. multiple recipients includes the keys of those listed, as you know them.

However, you could go some time before interacting with some people, longer even than two key expiry dates. I might get back in touch with a high school friend with whom I've had prior exchanges, and I'd have to reauthorize both new keys, even though having done so in the past, I could do so automatically and securely if the whole key chain were available. Seems a shame to be almost, but not quite there.

As for key compromise, I'd think in that case you'd simply have to simply start from scratch with a leap of faith, some shared secret challenge/response, or some out of band verification.

Sandro

[Jed Donnelley]

On 1/18/2016 3:24 PM, Alan Karp wrote:
> One way to handle key rollover is to start with two keys with different
> expiration dates, k1 and k2. Before k1 expires, you generate k3 and
> certify it using k2. Use k2 as your primary and k3 as secondary. Lather
> rinse repeat. This approach does not cover the case of a k2 being
> compromised, but its private key can be kept offline until
>
>
> --------------
> Alan Karp

Fine for when you need to bind a message to a person or organization.
My main point is that I believe by giving up a requirement for strong
binding the implementation and UI issues go away. In fact there is
no UI as the implementation is invisible as described.

With the approach I described keys come and go with email client
installations. They aren't bound to people but to email clients.
They can be created anew at will.

It's only in the rare case that one cares about binding an email
to a person (e.g. legal or financial) that most people even care
about such a binding. In that case I suggested that binding through
something like a secure web site is trivial. If the key changes,
bind again. I don't see a need for key rollover.

Do I care that the above message really came from you Alan?
I guess in some weak sense I do. I'd be a bit surprised and miffed
if it was sent by somebody doing a man in the middle attack.
Still, no big deal is my view. You are one of the relatively few
people on these lists that I've met in person. For me most of
the people on this list are identified by their email messages.
If their email client key doesn't change I can be assured they
haven't changed. If it does, big whoop. I probably wouldn't
even bother to try to link the two identities. If at some point
I did care THEN I'd work on a binding which I consider to be a
small problem technically, but a big problem for a user interface
that will be used by the great unwashed.

In any case with this current message I have no assurance
that the above message came from the you I've worked with.
I have no such assurance AND the email was sent in clear text
across the network.

Hmmm. Now that I think of it, however, I've been only considering
communication between two endpoints. What about email
communication like that of this list that is more multicast?
I guess in that case the Mailman (or whatever) server must
serve as an end. For that case any bindings would have to be
with the list server anyway. If my client knows all the destinations
(cc, bcc, etc.) then the point to point implementation works.
For a list server, however, it seems to me the server has to take
the role of an endpoint. Not a big deal IMO. In that case it would
be "nice" if the list server would let the list members know if the
client key of a sender changed - so people on the list could do a
new binding if they wished. Maybe just including a hash or id
along with the email address as the "from" so that anybody
concerned could notice which emails came from which Id/hash
and could do the work to bind them together if it became important.

Incidentally, David Nicol pointed out:

http://boingboing.net/2014/06/04/google-announces-end-to-end-en.html

Do others have relevant experience with that implementation?
I've been burned so many times trying to use PGP/GPG for encrypted/signed
email that I'm reluctant to try without a recommendation.