Subject: [openpgp] AS2+OpenPGP protocol extension review request

From: Ben McGinnes <[email-masked]>
Date: Tue, 12 Feb 2019 15:09:14 +1100

Hi all,
	For those of you either not subscribed to gnupg-devel or who
may not have paid as much attention to it over the new year period;
I've been working on a little thing which is ready for some form of
peer review.

Essentially it's a design for extending the W3C's ActivityStream
version 2.0 (AS2) and ActivityPub (AP) protocols for federated social
networks (e.g. Mastodon and Pleroma) with OpenPGP in order to provide
a host of features not inherently built into AS2 and AP.

The AS2 and AP designers considered it, but realised that they didn't
have enough cryptographic knowledge to design it in a way that
wouldn't shoot someone in the foot; and so they did the responsible
thing in not making assumptions.  Instead leaving things open for that
void to be filled later.

I found their work early last year and, upon reading the specs,
realised that I was looking at a transport protocol.  Not only that,
but all the most essential cryptographic functions which needed
filling were already thoroughly addressed by another existing
protocol: OpenPGP.

My post on this thing to the gnupg-devel mailing list is here:

https://lists.gnupg.org/pipermail/gnupg-devel/2019-January/034167.html

The W3C AS2 and AP specifications are here:

https://www.w3.org/TR/activitystreams-core/
https://www.w3.org/TR/activitypub/

My extension proposal is the second draft and the first draft that has
been posted publicly (the actual first draft was sent to the W3C AS2
designers, a couple of GnuPG developers and a handful of others).  My
design document is available here:

https://files.de.adversary.org/crypto/ac/index.html

The supplemental files (including public and private keys used in the
examples) are here:

https://files.de.adversary.org/crypto/ac/supplemental.zip

Note: files.de.adversary.org is an AWS S3 bucket, so it will trigger
an SSL cert error.  Ignore it or drop back to HTTP at your own
preference.

Anyway, there are a number of people on this list in particular who I
think could make sure that I haven't catastrophically cocked the whole
thing up.  I don't think I have, but that's precisely when you should
double-check to be sure.

So if as many of you as can spare the time could please weigh in and
try to pick it apart; that'd be greatly appreciated.  It'll help make
it stronger.  Those of you who've already been down the protocol
design path are amongst those I'm particularly keen on checking this
thing.

I do realise there are still matters to discuss and finalise with
regards to transmission of keys; currently there are multiple options
included and I expect some discussion around that.  There's also two
versions of the Encrypted Note and I'm inclined to favour the second,
slightly more complex version for a number of reasons; including
working with other functions (like nesting a Signed Note inside it in
a similar manner to signed & encrypted PGP/MIME emails).

Regards,
Ben

P.S.  I'm cross-posting this to the IETF OpenPGP WG mailing list on
      the off chance that there might be subscribers to that who are
      not also subscribed here or to gnupg-devel.  That may not be
      very likely, but it is possible and so a copy there doesn't
      hurt.  Apologies to those who will see it twice as result,
      though.  Especially since you're the ones I'm most keen to want
      reviewing this work.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Feb 2019 06:46:57 +0000

Ben McGinnes <[email-masked]> writes:

>Essentially it's a design for extending the W3C's ActivityStream version 2.0
>(AS2) and ActivityPub (AP) protocols for federated social networks (e.g.
>Mastodon and Pleroma) with OpenPGP in order to provide a host of features not
>inherently built into AS2 and AP.

Just a note on this, I don't know what the W3C's AS2 is but whatever it is
it's nothing like the real AS2, which is a secure EDI standard that's been
around for close to twenty years (there are actually several AS standards, but
the most widely-used one is AS2).  So if anyone goes looking for AS2 security
information, they're going to get a very different AS2...

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Feb 2019 11:52:05 +0000

Hiya,

I just had a quick peek (will try read more later) but wondered
why PGP is a better primitive here than MLS? [1] (Or one of the
IM security schemes that motivated MLS, if dealing with a work-
in-progress like MLS is problematic.)

Ta,
S.

[1] https://tools.ietf.org/wg/mls/charters

On 12/02/2019 04:09, Ben McGinnes wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Ben McGinnes <[email-masked]>
Date: Thu, 14 Feb 2019 17:23:03 +1100

On Tue, Feb 12, 2019 at 06:46:57AM +0000, Peter Gutmann wrote:
> >version 2.0 (AS2) and ActivityPub (AP) protocols for federated
> >social networks (e.g.  Mastodon and Pleroma) with OpenPGP in order
> >to provide a host of features not inherently built into AS2 and AP.
> 
> Just a note on this, I don't know what the W3C's AS2 is but whatever
> it is it's nothing like the real AS2, which is a secure EDI standard
> that's been around for close to twenty years (there are actually
> several AS standards, but the most widely-used one is AS2).  So if
> anyone goes looking for AS2 security information, they're going to
> get a very different AS2...

Ah, oops; well there's a good reason to drop initialisms and acronyms
from draft #3.

The W3C's thing is a protocol for social networking and micro-blogging
which is implemented largely in JSON format.  It grew out of the GNU
StatusNet thing, except it's clearly defined (StatusNet was a bit
hodge-podge).  Since it's federated, it's beginning to pick up a fair
bit of traction amongst the growing number of social network users who
have become disatisfied with the likes of Twitter and FarceBook.

Well, I'm not overly fussed about needing to use a short term for
these things beyond just for my own quick references during drafting;
so I'm quite happy to drop it in order to avoid future confusion.

Regards,
Ben

---

From: Ben McGinnes <[email-masked]>
Date: Thu, 14 Feb 2019 17:49:43 +1100

> in-progress like MLS is problematic.)

I was about to say MLS is *way* overkill, but then realised you were
referring to the more recent MLS[1] and not this MLS.[2]

Anyway, there were several reasons; including, but not limited to,
these:

 1. Responding to frequent requests of users of Mastodon and Pleroma
    servers who have been requesting specific software solutions of those
    platform (most commonly citing Mailvelope or Keybase).
    
    I wanted to get the thing out of the realm of vendor or language
    lock-in.
    
 2. ActivityStreams 2.0, in spite of the name, does not actually use
    live streamed data in the same way as various IM protocols do, it
    really is a transport protocol only.
    
 3. OpenPGP provides an existing and proven means of meeting all the
    cryptographic shortfalls of ActivityStreams and the fediverse.
    
 4. I've deliberately designed this extension in a way which would
    enable an alternative cryptosystem to be designed for it or adapted
    to it in the future.  So no protocol lock-in either.
    
 5. None of the IM cryptosystems I thought of would meet all the needs
    of various people whose requests I read and most of them are solely
    dependent on either SSL or libsodium to the exclusion of all else.
    The former tends towards mis-implementation and various exploits, the
    latter tends towards trying to make the one thing it does do fit
    everything.
    
    It could be argued that that latter criticism is also true of
    OpenPGP, but on the other hand OpenPGP and, particularly GnuPG,
    can do an awful lot more too.
    
 6. I've spent far more time delving into GnuPG's innards than most of
    the other systems, so there was a little bias there.  Still, that's
    another reason for defining the spec in such a way that an
    alternative cryptographic protocol could be used instead.

Regards,
Ben

1: https://tools.ietf.org/wg/mls/
2: https://en.wikipedia.org/wiki/Multilevel_security

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 15 Feb 2019 03:19:08 +0000

Ben McGinnes <[email-masked]> writes:

>Ah, oops; well there's a good reason to drop initialisms and acronyms from
>draft #3.

Yeah, I think both AS2 and MLS, which someone else pointed out, have such a
long history of use in the security community that it'd be better to look for
non-conflicting terms.

Peter.

---

From: Ben McGinnes <[email-masked]>
Date: Sat, 16 Feb 2019 07:11:35 +1100

On Fri, Feb 15, 2019 at 03:19:08AM +0000, Peter Gutmann wrote:
> Yeah, I think both AS2 and MLS, which someone else pointed out, have
> such a long history of use in the security community that it'd be
> better to look for non-conflicting terms.

Indeed; and as a Pythonista I am reminded of the second line in the
Zen of Python, “Explicit is better than implicit.”

That certainly applies here.

Now, if that and a final decision on key sharing within the protocol's
scope are the only real issues here, I'll be very happy (and somewhat
amazed with myself).

I'd rather be sure, though, so if you could find the time for a bit of
a closer look, I'd greatly appreciate it.  No doubt eventual end users
would appreciate it more, albeit without the concious recognition of
that (in most cases).

Regards,
Ben