[messaging] Thoughts on keyservers

[elijah]

On 08/18/2014 06:18 PM, Nadim Kobeissi wrote:

> There's a lot of vague promises that are bundled with this model. For
> example that "the notaries are continually audited." Is this really the
> practical scenario?

Auditing is an attempt to achieve or approximate a global view into the
key space. Many approaches for binding user identifiers to keys have
some kind of auditing (see below). It is very useful to be able to ask
"is the version of reality that i see the same one that everyone else
sees, or am I being fed bullshit?" Is this practical? Probably more
practical than the alternative.

> Sticking to PGP is confusing. We have many protocols and projects out
> there (Axolotl, or miniLock) that are focusing on primitives that are
> newer, leaner and that offer new venues for key management. Matthew
> Green recently wrote an excellent piece on this [1]. I also saw this
> pretty comic comparison of PGP's primitives to Cure25519 today [2].
> 
> The fact that folks are resorting to such lengths to try and save PGP is
> just clear indication that it's time to move on.

Unless one feels that short keys magically produce good user experience,
the topic of this thread does not have anything to do with OpenPGP, per se.

I say this because no matter what type of public key you want to use you
will have the same problem of key validation. There are a finite number
of potential strategies that people have dreamed up, only one of which
is made easier with short keys:

Decentralized:

* Don't use human memorable identifiers and just use the key or
fingerprint as the identifier, possibly facilitated by using some
usability trick like Qr codes or short authentication strings.
* Non-verbal confirmation plus SAS (zrtp)
* Shared secret
* TOFU (albeit a very poor form of TOFU since there is no forward
validation)
* Web of Trust

Infrastructure based:

* Central authority, or finite set of authorities
* Consensus among a finite set of authorities
* Global append only log
* Multiple append only logs
* Network perspective
* Authority call-back

Many a very smart person has said, "screw this, the problem is too hard,
lets just use keys as identifiers." Maybe they are right in the short
term, but in the long term there is every reason to expect this problem
to be solved and for humans to eventually enjoy human friendly identifiers.

Although Matthew Green is usually astute, I thought his post on OpenPGP
was very disappointing. OpenPGP is flexible, and most of his criticism
consisted of straw man arguments regarding existing software and
existing practice, not the protocol itself. Few have railed against the
how people use OpenPGP more than I, but there is an important
distinction between problems inherent in the space (like validation and
pfs) and problems with OpenPGP.

Yes, some people have a legitimate beef about non-repudiation, and it is
stupid and easily fixed to not encrypt the subject, but async PFS is
something on which the dust has not settled. I love Axolotl, and I think
the choice of pre-keys is an acceptable concession, but plenty of
reasonable people do not agree.

Yes, actual OpenPGP implementations have bad defaults, are too flexible,
and let you do horrible things (like fetch via fingerprint and think
that means the fingerprint has been verified). But it is also a fracking
work horse that runs a lot of important things. Any reasonable system to
change how we do secure email can include a mechanism for capabilities
discovery, and switch between S/MIME, OpenPGP, Axolotl, or whatever as
appropriate. Creating a replacement for OpenPGP and S/MIME might be
hard, but it is probably the easiest part of trying to make email secure
and easy to use.

-elijah