Your Thoughts

[Robert J. Hansen]

> I think the article is five years old, has not aged well (e.g. MUA
> integration has improved), and that nothing better than PGP has come
> along in the meantime.
I think Matthew Green is a very sharp fellow and his criticisms are
thoroughly on-point.  My biggest complaint about that article is that he
doesn't draw a clean distinction among the OpenPGP specification, how
software packages like GnuPG choose to implement the specification, and
the supporting ecosystem that is neither OpenPGP nor implementation.

The OpenPGP spec says surprisingly little about what the format of a key
should be, for instance.  If you look at GnuPG's key export format, it
was chosen in the late '90s to be interoperable with PGP Security's PGP
5.0 offering (which was, at the time, pretty much cutting-edge).

Well -- nowadays GnuPG is the big mover in that space.  There's a strong
argument to be made that GnuPG should be more of an innovator.  There's
no reason anymore to retain the old and inefficient PGP 5 format.  We
can change it and still be compliant with the spec: maybe we should.  I
think we should.

And hey, if we fix the key exchange format, that's one massive section
of his objections gone.  That set of objections isn't to OpenPGP, it's
purely about how we implement it.

Another major complaint of his is the keyserver network, which we've
known for years was inadequate.  It was also the only game in town and
there was neither the money nor the manpower to do a better job.  Now
we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
most mature and the easiest for email users.  We've got three at least
arguably better ways of distributing certificates: if we can actually
persuade people to start using them, we can fix this and wipe another
set of complaints off his list.  His set of objections here is not to
either OpenPGP or an implementation of it, but rather the support ecosystem.

(Note to anyone who thinks I'm saying "it's kinda good that this Great
Unpleasantness is happening because it's making people migrate": no.
Absolutely not.  The people behind this deserve to be shunned by our
community and exiled from our mailing lists.  They are not our friends.)

About the only actual protocol-level complaints Professor Green has are:

1.  OpenPGP has no forward secrecy.  (Correct!  I'd love to see the
OpenPGP Working Group tackle this.  I'm not sure it can be done for
offline asynchronous communications, but it would be good to at least
investigate the possibilities.)

2.  OpenPGP has no AE/AEAD mode.  (Incorrect!  The MDC is a form of
authenticated encryption.  It predates modern AE/AEAD and looks kind of
baroque to modern eyes, but it's AE.  The fact some mail clients
*ignore* the AE is a different [and very serious!] matter.  Further, the
latest RFC4880bis spec -- which was written after Professor Green's
blogpost -- explicitly incorporates modern AE/AEAD.)

My complaint about Professor Green's blogpost is that he treats PGP as a
single monolithic block, instead of as different plants in a garden that
all grow interdependently.  The OpenPGP protocol is solid.  But we can,
and I think we need to, do a serious modernization pass on how we choose
to *implement* that protocol.

If I were to set priorities for GnuPG?

1.  Set a flag day.  Past a certain date, old-and-busted certificates
and data formats will simply not be supported.  They won't be written,
they won't be read, they won't be processed, GnuPG will simply say
"nope, that might be legit old-school RFC4880 traffic but I'm not going
to play that game."

2.  Overhaul the key format.

3.  Do away with user IDs.  Only use key IDs.  If a user wants to
associate a key with an email address, let them: but user IDs originally
existed *mostly* to support the email use case, and with the advent of
Autocrypt that's not such an issue any more.  (Note that a lot of thorny
problems suddenly just *go away* if you stop using userIDs.)

4.  Require a limited subset of the RFC4880bis standard to be used.
Keep support for adding ciphers to the spec -- algorithm agility is a
wonderful thing -- but by default only use one specific ECC algorithm in
one specific key length, with AES256 as a symmetric cipher, and SHA512
for a hash.  GnuPG's ability to support arbitrary preferences and
algorithms is neat technically but I have literally *never* seen it be
necessary in field usage, and I have seen people accidentally degrade
their security literally *hundreds* of times.  (If your cipher
preferences are 3DES AES128 AES256, for instance?  Say hello to 3DES:
you will literally never use AES256.)

5.  If we're going to continue to have a keyserver network the only way
forward is to burn it down and build something newer and better.  There
are no other realistic options.

6.  Develop a well-defined output format.  Werner & co. like to say the
output of --with-colons is well-defined.  It's not.  Unless there's
something like a DTD or a BNF specification and the output can be
formally verified against the specification, what you have is ad hoc.
The processing bugs the Efail paper exploited were overwhelmingly caused
by MUA authors misunderstanding or misinterpreting the output GnuPG was
giving it.


... Would this be painful?  Sure.  But it doesn't involve throwing out
the OpenPGP spec, just overhauling how we implement it and the
supporting software ecosystem.  That would be *hard*, don't get me
wrong, and I am *in no way* saying this would be easy.

But worth it?  I dunno.  Maybe.  Yeah.  Let's throw it out there, let's
talk about it.

But that's just me.  :)