Subject: Re: [Endymail] Another view of the problem and what the IETF could do

From: Werner Koch <[email-masked]>
Date: Mon, 01 Sep 2014 12:24:47 +0200

On Wed, 27 Aug 2014 18:21, [email-masked] said:

> This is a big problem. The PGP Web of Trust has failed, and we’ve all heard

It did not fail; it is just as inconvenient as paying a CA for a
questionable service.  Any extra inconveniences are not good for mass
use of encrypted mails.

> the griping about the CA biz.  Joe Hildebrand mentioned POSH & WebFinger
> and they’re both interesting.  I’m also interested in the notion of a key

They requires that you are always online and thus the service provides
my track even signature verifications.  Without an anonymity
guaranteeing infrastructure this may only be an intermediate solution.

> 5. Display the message appropriately, depending what it is
> This is a problem.  Lots of the messages I want to send are movies or songs
> or pictures, and if there’s no way to communicate the Media Type, it’s less
> useful to the recipient.

You mean for the encrypted data or for the cleartext?  OpenPGP has a
feature to convey the media type - not much options right now but it is
easy to extend.  Or use the standard way and encrypted the MIME
container.

Shalom-Salam,

   Werner

p.s.
BTW, a few years ago we came up with the http://g10code.com/steed.html
proposal.  Unfortunately it didn't worked out because the mail
providers had zero interest in supporting even a prototype.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 1 Sep 2014 12:48:45 +0200

The web of trust hasn't failed?

The number of people with email addresses has grown to perhaps a quarter of 
humanity. Meanwhile, the number of people who use PGP seems to have been 
more or less stable for the past 15 years (I'd love to see better numbers 
on that, but who might be in a position to collect that?). What's the 
threshold for success then?

Arnt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Sep 2014 12:32:43 -0400

On Mon, Sep 1, 2014 at 6:48 AM, Arnt Gulbrandsen
<[email-masked]> wrote:
> more or less stable for the past 15 years (I'd love to see better numbers on
> that, but who might be in a position to collect that?). What's the threshold
> for success then?

One of the main reasons PGP failed is that people wanted it to succeed
so desperately. So nobody would speak up about the problems. As if
wishful thinking alone would solve everything.

Robert Owen, the father of the factory system set up a socialist
utopian commune in the US which was the first of its kind. It failed
in the exact same ways that numerous later attempts also failed.
Because people didn't want to question the ideology and acknowledge
the problems which is the first step to solving them. Other communes
did look at the problems and did not fail in the same ways.

No one trust model is going to fit every need. Which is why the trust
model mechanics should be separated out from the client for the time
being.

One very powerful tool for addressing the problem is that we
distinguish the first contact use case from the continued contact use
case.

Alice is sending a message to Bob, she has never met Bob in person,
she has only got his email address from a Web site. But it is Bob she
wants to talk to and this might not be [email-masked].

So in this situation I don't think she is going to be immediately
sending Bob really confidential secrets. I think it is going to be
perfectly adequate to use key distribution mechanisms such as key
servers and the like for establishing this connection.

Securing further conversation is quite a bit easier. We can exchange a
fingerprint in band and make Alice enter it manually or we can use
strong email addresses which are just a bit of syntactic sugar (aka
usability) thrown on top.

We can even send the contact information inband in email headers:

To: <[email-masked]>
From: <[email-masked]>
Reply-To: <[email-masked]>
Encrypt-To: <ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?[email-masked]>

Hi Bob, wanna talk to me?

Unlike PEM headers, we are not sending several Kb of extra data per
message. We are only sending the information required to locate the
cert chain and validate it. We are not sending unnecessary data.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Sep 2014 18:49:39 +0200

Hi Tim,

You've written in narrative a great table of tasks.  But...

On 8/27/14, 6:21 PM, Tim Bray wrote:
>
> 1. Find a public key for the user that the sender’s prepared to trust.
>
> This is a big problem. The PGP Web of Trust has failed, and we’ve all
> heard the griping about the CA biz.  Joe Hildebrand mentioned POSH &
> WebFinger and they’re both interesting.  I’m also interested in the
> notion of a key directory with associated proofs that you don’t have
> to trust, for example the one from https://keybase.io
> <https://keybase.io/>.  In particular
> see https://keybase.io/docs/server_security
> WORK FOR IETF: Get pro-active on key discovery/trust work? Standardize
> key search APIs?

If the IETF could solve but this problem such that it scales to the size
of the Internet, everything else on your list would I think fall into
place.  Unfortunately, key management really wasn't on your list, and
that has to be addressed as well.  Also, I suspect that email programs
probably need to evolve a bit to cope with all of this.  Case and point:
I'm pretty sure I've lot one or two private keys along the way.  And, at
least compared to your average Joe, I'm good at this.

BTW, it all has to happen without asking for matching keys.  Enigmail
does a pretty good job of that already.  That's a pretty good model for
UI (I hazard a guess), and so stay focused on how to get it to function
to scale.  It may make sense to use some form of OTR for end-to-end
transit.  But again I wouldn't want to count on OTR for data at rest.

Eliot

---

From: Tim Bray <[email-masked]>
Date: Mon, 1 Sep 2014 10:16:12 -0700

> 1. Find a public key for the user that the sender’s prepared to trust.
...
> If the IETF could solve but this problem such that it scales to the size
of
> the Internet, everything else on your list would I think fall into place.

​These days, I’m all excited about the keybase.io model.  Since I’ve
already held forth​ on this, let me just add that anyone who’s interested
in a closer look, it’s in closed beta but I have loads of invites, shoot me
an email and I’ll ask you in.

NOTE: I haven’t developed an opinion yet about the actual keybase.io
project itself because I don’t fully understand what they’re trying to be.
 But I find the model genuinely exciting.

> Unfortunately, key management really wasn't on your list, and that has to
be
> addressed as well.

Good point, I agree 100%.  I’m aware of some mobile apps that are taking a
seriously-good run at solving the UX part of the problem; obviously, that’s
just as hard/important as the crypto and data security and so on.   I’m
starting to wonder if maybe hardware-based approaches along the lines of
what the FIDO people are working on are the best approach: Your data is key
is on your keychain; physically, in your pocket, right beside your house
key.

 Also, I suspect that email programs probably need to
> evolve a bit to cope with all of this.  Case and point: I'm pretty sure
I've
> lot one or two private keys along the way.  And, at least compared to your
> average Joe, I'm good at this.
>
does a
> pretty good job of that already.  That's a pretty good model for UI (I
> hazard a guess), and so stay focused on how to get it to function to
scale.
> It may make sense to use some form of OTR for end-to-end transit.  But
again
> I wouldn't want to count on OTR for data at rest.
>
> Eliot

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Werner Koch <[email-masked]>
Date: Tue, 02 Sep 2014 09:53:10 +0200

> The web of trust hasn't failed?

The WoT is only a part of OpenPGP and actually never specified.

Sure, mass-acceptance of encrypted mail failed but not due to the WoT.
If you ask OpenPGP users you will notice that most of them entirely
ignore the key validity issue and at best use local signature to mark
keys valid.  Does this help?  No, people still complain that encryption
looks too complicated and they turn over to the next hottest
surveillance service claiming that there they have nothing to hide
anyway.

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Tue, 02 Sep 2014 10:07:33 +0200

> UI (I hazard a guess), and so stay focused on how to get it to function

It has been told so often in all kind of media that Enigmail is the best
tool to use.  I suggested its use myself up until I helped out at a
crypto party and figured that the UI is still made for geeks and not for
users.  For example, one participant assumed that he had decrypted a
mail after having entered his passphrase 3 times.  Then wondered why
there was only this BEGIN PGP MESSAGE and some rubbish.  He didn't
realized that he entered the wrong passphrase 3 times in a row.  The fix
would be obvious: Print the "wrong passphrase" in bold and red letters
and after the 3 tries show an explanations what happened in the content
window.

But how can we expect to get things better with only two spare time
developers for Enigmail and just me taking care of the backend stuff?
Business models around solid encryption have always failed.

> transit.  But again I wouldn't want to count on OTR for data at rest.

I fully agree.

Shalom-Salam,

   Werner

---

From: Steffen Nurpmeso <[email-masked]>
Date: Tue, 02 Sep 2014 12:42:17 +0200

Werner Koch <[email-masked]> wrote:
 |On Mon,  1 Sep 2014 12:48, [email-masked] said:
 |> The web of trust hasn't failed?
 |
 |The WoT is only a part of OpenPGP and actually never specified.
 |
 |Sure, mass-acceptance of encrypted mail failed but not due to the WoT.
 |If you ask OpenPGP users you will notice that most of them entirely
 |ignore the key validity issue and at best use local signature to mark
 |keys valid.  Does this help?  No, people still complain that encryption
 |looks too complicated and they turn over to the next hottest

If with introduction of the new german passport every receiver had
also obtained a set of usable PGP and OpenSSL S/MIME keys and/or
certificates -- at best with a small info flyer which would have
shown how to import those into the tools of the most widespread
operating systems -- the situation would surely be better in
Germany.

Not that this means that some kind of people won't go with hypes
anymore, but i am sure for most people, Germans that is, WoT had
to be something from the "ultimate" (or only real) authority, and
would then be used just the same way as one uses the passport.
Note that this would also cutdown the complexity of key handling,
the sheer amount of keys to be managed, which can be kind of
frightening if you're unlucky.

So unfortunately that didn't happen, and "ca-certificates" does no
longer include CACert.org because people are playing games or
misusing their anonymity for whatever reason, so where does
a normal person get their free S/MIME environment from (the list
already has seen those approaches that are not really usable for
a normal person).

Providers could include a free certificate with each account,
which would enable their users to choose security by themselves
(on a per-provider basis).
A SMTP-server-chain-of-trust can prevent STARTTLS MITM by simply
assuming TLS (which didn't become SMTPS via port 465 for reasons
that i don't know, yet NetBSD's /etc/services still lists this
relationship and my free mail provider offers the service as
such).
I personally never liked DNSSEC; UDP packet sizes can be
enlargened etc., but usage of TCP is in the protocol, and then
protected right away via TLS i would have preferred, and
ca-certificates are installed wherever i am.
Of course my opinion is rude and simple and doesn't deliver.

--steffen

---

From: Leo Vegoda <[email-masked]>
Date: Tue, 2 Sep 2014 17:02:06 +0100

On Tue, Sep 02, 2014 at 12:42:17PM +0200, Steffen Nurpmeso wrote:

[...]

> operating systems -- the situation would surely be better in

I think it is much easier to impersonate someone by e-mail when you
have the private key to their identity than when you steal a
passport. The picture in the passport means that most men cannot use
a stolen woman's passport, and most kids cannot use an older
person's passport, and so on. But with the private key to an
identity someone can be impersonated over e-mail by almost anyone.

For these reasons, I do not think that handing out cryptographic
identities would be responsible unless there was a suitable key
management framework for people to use and they knew how to use it.

[...]

> (on a per-provider basis).

Do you mean providers of e-mail services? 

Handing out cryptographic identity certificates or similar to people
who do not understand the risks or benefits and do not have a
suitable key management framework doesn't seem a great idea to me.

I think it makes more sense to start with the fundamentals rather
than hoping they'll come along some time after widespread
deployment.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Sep 2014 17:22:16 +0100

I'm not quite sure I'm reading this correctly, but just in
case...

> suitable key management framework doesn't seem a great idea to me.

If this list concludes that an Internet-scale key management
framework is required where all key holders are strongly
authenticated before they get any functional benefit, then
that makes life easy - we have 20+ years of evidence that
there's no point in bothering to try construct that;-)

Similarly, if the list concludes that users have to understand
keys then that's also easy - we know that will never happen
and so could also call it a day.

Luckily I don't think most folks are making those mistakes
but we really shouldn't spend any more time than absolutely
needed on discussion that assumes that the Internet only
has strongly authenticated keys or only has users who
understand cryptographic keys.

If someone reading this is not convinced already, please
mail me offlist and I'll try set you right, but let's not
reinvent X.400 email security here please? (Or PEM, or MOSS,
or S/MIME or PGP or STANAG 4406 or the various national or
proprietary variations etc.)

S.

---

From: Leo Vegoda <[email-masked]>
Date: Tue, 2 Sep 2014 20:47:06 +0100

> there's no point in bothering to try construct that;-)

That's not quite what I meant. What I meant is that if there is an
authority handing out certificates then it should do so in a
responsible way. Cryptographic certificates are sufficiently
different from photographic identity documents that pre-existing
assumptions need to be changed to avoid disappointment.

This does not need to be hierarchical but it does need some
infrastructure support and either some really outstandingly good
user interface design or education. If users receive encrypted
e-mail and then loose the corresponding private key then they loose
the ability to read old messages. People working for organizations
handing out X.509 certificates for S/MIME use get training and their
keys might well be escrowed. But ordinary individuals are unlikely
to get training and they do expect to be able to read old e-mails. 

I think this is the sort of basic usability issue that requires some
kind of user friendly key management. Whether it needs to be
Internet-scale - well I don't know - but it needs to be good enough
that the key is reasonably secure if a laptop or tablet is lost or
stolen. 

I expect that in most cases strong authentication is not required
but people will need some kind of mechanism for evaluating how much
trust to assign a new key they have not seen before and that will
also require some kind of education or another superb user
interface. Most people will be new to cryptography and will need
some help.

Leo

---

From: Adam Caudill <[email-masked]>
Date: Tue, 2 Sep 2014 16:03:39 -0400

On Sep 1, 2014, at 12:49 PM, Eliot Lear <[email-masked]> wrote:

>> This is a big problem. The PGP Web of Trust has failed, and we’ve all heard the griping about the CA biz.  Joe Hildebrand mentioned POSH & WebFinger and they’re both interesting.  I’m also interested in the notion of a key directory with associated proofs that you don’t have to trust, for example the one from https://keybase.io.  In particular see https://keybase.io/docs/server_security
>> WORK FOR IETF: Get pro-active on key discovery/trust work? Standardize key search APIs?
> 
> If the IETF could solve but this problem such that it scales to the size of the Internet, everything else on your list would I think fall into place.  Unfortunately, key management really wasn't on your list, and that has to be addressed as well.  Also, I suspect that email programs probably need to evolve a bit to cope with all of this.  Case and point: I'm pretty sure I've lot one or two private keys along the way.  And, at least compared to your average Joe, I'm good at this.

No matter what the path forward is for secure messaging, key discovery (and reasonable key management) will be the cornerstone. If we don’t have solid public key discovery, then I fear we’ll just end up reinventing PGP.  For a system to scale to the same level email as we know it has, there needs to be transparent key discovery so that the average user need not be aware it’s even happening.

In the design I’ve been working on, it’s the responsibility of the messaging service provider to host a user directory, with signed updates that senders can use to get the proper key for a user (so, example.com would provide the sender with the info they need to send to [email-masked]).

I really think this needs to be a primary focus, and as Tim pointed out, this is something that makes sense for the IETF to work on. If we can establish a solid solution here, I agree completely with Eliot here, the rest will fall into place - and will open the door to many good options.

-- 
Adam Caudill
[email-masked]
http://adamcaudill.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Sep 2014 16:36:04 -0400

On the key discovery problem, there are several separate questions:

1) I want to send email to Alice Splunge, what is her email address and what is her trust anchor

2) I know Alice Splunge has email address, [email-masked], what is her trust anchor

3) I know Alice's trust anchor and email address, what public key should Bob Cratchet use to send her email?

Some of these questions are easier to answer than others. Which is why I distinguish trust anchor discovery (i.e. discovering the hash of a key that signs a security policy) from key discovery. 

Since spam is a concern, we might well not want to answer question 1, or at least not to just anyone. But we might distribute keys through social networks. So I my might not publish my email address on my Web site (I do actually) but I might put it on my linked in profile complete with my trust anchor.

For in person trust anchor exchange, QR codes are the way to go.

Sent from my iPad

> On Sep 2, 2014, at 4:03 PM, Adam Caudill <[email-masked]> wrote:
> 
> _______________________________________________
> Endymail mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/endymail

---

From: Tim Bray <[email-masked]>
Date: Tue, 02 Sep 2014 23:54:21 +0100

Just to add another 2p in the pile.

Does anybody have a view on https://telegram.org/

It is a whatsapp clone which claims to have reasonably strong encyption, 
with optional end to end encryption.  They make some fairly bold claims 
about security on their website.  The client side is open source.

It is one of the best to use IM on your phone apps I've used.

I'm told there are some scathing writeups about the encryption.  I'm not 
enough of a crypto person to be able to reason about these.

Telegram do store (non secure) chats on their server side, and they sync 
between devices very well.  Downside for crypto/intercept.  Good for 
usability.

The server side isn't open source, and is run by the service operator. 
You can't install your own, and no server to server comms.

But, it is a very very usable service.  It does what it says on the tin. 
  It is how a service aimed at a mass user base has to be.

I'm not suggesting telegram is an answer.  Just something to look at for 
inspiration.

Tim

-- 
Tim Bray
[email-masked] | +44 7966 479015 | http://www.kooky.org
Huddersfield, UK

---

From: Werner Koch <[email-masked]>
Date: Wed, 03 Sep 2014 09:22:37 +0200

> and so could also call it a day.

Users do understand mail addresses and thus a key should be identified
by the mail address and not by any other property.

> reinvent X.400 email security here please? (Or PEM, or MOSS,

What problem do you see with MOSS?  Except for the commonly ignored
micalg parameter it is a well working part of MIME and not a problem at
all.  This is true for S?MIME as well as for PGP/MIME.  We are still
talking about mail, tight?  Or is the goal of the list to replace the
rfc822 mail format - that will never happen in the foreseeable future.

Salam-Shalom,

   Werner

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Sep 2014 11:53:39 +0100

On 03/09/14 08:22, Werner Koch wrote:
> What problem do you see with MOSS? 

Its irrelevance:-) Is it actually used for anything?

I note the RFC [1] is now historic and as far as I know
its not in use. I'm not saying its technically good
or bad, (more good than bad is my recollection but I've
not re-read it) but it failed in terms of adoption.

S.

[1] https://tools.ietf.org/html/rfc1848

---

From: Werner Koch <[email-masked]>
Date: Wed, 03 Sep 2014 13:08:07 +0200

> I note the RFC [1] is now historic and as far as I know

Oops my fault.  For the last 15 or so years I used the term MOSS for
1847 "Security Multiparts for MIME" in my mails, talks, and slides.
That was clearly wrong.  I entirely forgot that MOSS (1848) was an
protocol based on 1847.

Salam-Shalom,

   Werner

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 3 Sep 2014 10:55:35 -0400

> rfc822 mail format - that will never happen in the foreseeable future.

I think we should be open to a possible change for messaging in general and
not limit ourselves to mail.

-- 

Best regards,
Kathleen

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Sep 2014 14:54:42 -0400

> not limit ourselves to mail.

Totally and I think changing messaging in general is likely to be the
area where we eventually end up changing application protocols. If we
are just fixing email security then obviously we play SMTP. If we are
doing messaging then we just layer security onto Jabber.

But if we decide that we are doing security for messaging in general,
both synchronous and asynchronous, bilateral and multilateral then
cutting out the cruft and going to a consistent JSON based messaging
infrastructure with security built in from the start and a key service
that doubles as a presence service starts to look a lot simpler than
ad hoc backfixes to each protocol in turn.

But.

The reason I am sticking with email right now is that it is the single
hardest problem and if we can solve that one, we can leverage the
solution for every other area as well. What makes email hard is that
it is asynchronous and the store and forward protocols don't separate
content and data channels. So all control signaling takes place in the
content space or not at all. These days increasingly not at all, I
don't see bounce messages very often any more.

---

From: Michael Kjörling <[email-masked]>
Date: Thu, 4 Sep 2014 13:18:56 +0000

On 2 Sep 2014 16:36 -0400, from [email-masked] (Phillip Hallam-Baker):
> Since spam is a concern, we might well not want to answer question
> 1, or at least not to just anyone.

This is one of the points I raised in [1], and which frankly I felt
went unaddressed.

> For in person trust anchor exchange, QR codes are the way to go.

Only if you're willing to basically limit "whatever we end up
discussing" to people who have the ability to process a random
encountered QR code in the field. While smartphones and ubiquitous
networking is common in many Western countries, designing a protocol
around only that seems rather excluding. Just to mention one example,
I myself would have no way to process that QR code, and found myself
in a discussion on a non-technical mailing list the other day where
several people commented about either not having cell phones at all,
or having only old "dumb phone" style phones.

Do we want to exclude those people from establishing that trust
anchor?

[1] Fri, 29 Aug 2014 09:11:33 +0000 http://mailarchive.ietf.org/arch/msg/endymail/mSmLHfs0kzZNE9LaYdBDjHtN8ok

-- 
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: Leo Vegoda <[email-masked]>
Date: Thu, 4 Sep 2014 06:27:05 -0700

On Thu, Sep 04, 2014 at 01:18:56PM +0000, Michael Kjörling wrote:

[...]

> Do we want to exclude those people from establishing that trust

Is it sensible to design a technology based around currently
deployed capabilities or oshould the design assumptions extend to
those capabilities that are likely to exist at the conclusion of the
work or shortly afterwards?

I know there are reasons that people might not want to use
cameraphones in some industries, and that might well limit the
utility of QR codes. However, it seems reasonable to anticipate
cameraphone technology reducing in price and becoming more
widespread in the next five years.