Re: improving key exchange over ActivityPub

I did some early work on this several years ago (in the OStatus days),
however the proposal I pitched at the time to Mastodon to provide a
generic delivery system for keys in arbitrary formats (i.e. text or
byte stream), which would have enabled me to implement end-to-end
encryption, was rejected in favour of an proprietary integration with
Keybase. Gargron seemed to be of the opinion that if it couldn't be a
proprietary, strong-defined key format it wasn't worth implementing.

Having then later realised Keybase integration was a mistake, Mastodon
then decided to implement Olm but in such a way that a malicious
administrator could fairly easily (with some patience) compromise the
identity by swapping out the keys (as far as I can tell from a glance
anyway) (see https://github.com/mastodon/mastodon/pull/13820). This is
the classic E2E 'mistake', trying to abstract identity management down
to an isolated key and cipher problem. To my knowledge no-one uses
this?

The proposal from Ben McGinnes is effectively the same as what I
pitched prior, although the reference implementation wasn't using
OpenPGP. One notable difference is that this the proposal ties
identity to key ownership exclusively, which requires you to be
confident of the identity of recepient and provides no means for
deconfliction.

My initial plan several years ago had been to provide for key identity
deconfliction through independent servers - this would provide a
degree of configuratability for different threat models and risk
appetites. However, without any way to reliably acquire keys from a
profile it either relied on completely outsourcing key management to
third-parties or including the key in the profile description (which,
at the time, had a very restrictive character limit by default in
Mastodon - people didn't like the idea of using half their profile
text on a key). Eventually when Gargron declined to provide the
capability to attach public keys to a profile, when combined with the
other existentials issues with implementing E2E across the Fediverse
(which are plentiful) I ultimately decided to shelve the (functional)
project as I concluded the ultimate usability versus security benefit
was too low for adoption (based on early user testing). There was also
the issue that none of the Mastodon clients were really interested in
being early adopters - they all adopted a wait and see approach -
which meant I had to produce my own client which was inherently
inferior due to simply spreading my time too thin.

I more recently spent a couple of days brainstorming different models
for E2E to see if I could improve the threat model, but after coming
up with half a dozen different methodologies concluded that the need
to ensure messages make their way to the correct parties still makes
any degree of privacy and anonymity (i.e. metadata resistance,
identity verification) very difficult, with complex trade-offs that
end-users are unlikely to accept. Fundamentally if an adminstrator can
see all the metadata or perform a trivial MITM social engineering
attack it's probably not worth doing. The user experience for
correctly handling deconfliction in the case of a MITM attack is
inherently quite different in itself - the idea behind having multiple
independent servers is that you could reduce it to a Byzantine
Generals problem at least. By creating a web of trust (but not a Web
of Trust) you can remove a degree of need for a 'wallet' or as I like
to call it a 'single human-controlled point of fatal failure'. Think
how many cryptobros have lost their cryptocurrency wallets and then
imagine if that was your entire online identity - the severity of this
varies from person to person. Having different types of identity
providers with only loose trust would allow people to effectively pick
and choose their risk appetite for certain types of risks. It might be
that you would have an identity provider which only verified
real-world identities according to, say, financial standards, while
you might have another identity provider which relied on ownership of
a key wallet, and another which worked on a whisper network. None is
inherently 'better' than another, but may form part of a deconfliction
process when an identity is trespassed or lost. Such was/is my
thinking.

I feel if we want to pursue this effectively it should be its own
project with ActivityPub extension forming only a small part of the
work. My feeling is effective decentralised identity management is too
tightly intertwined with social and technological factors apart from
the protocol to be solved by addressing it at the ActivityPub level. I
suspect concepts like the Nomad protocol or Decentralised Identities
are... sufficient to serve as anchors for an initial implementation,
but anydependency on 'wallets' is an obvious failure point. If that's
not feasible, then I'm still of the opinion that simply allowing the
attachment of a key to a profile is part of the solution (but
certainly not the whole solution) - just please don't tie it to any
pet cipher/protocol; there's no need.

-Danny AKA Rushyo

On Wed, 7 Dec 2022 at 01:51, Sean O'Brien <sean.obrien@yale.edu> wrote:
>
> Hi all,
>
> I'm unfamiliar with the process at W3C, but I see a general trend on the
> messages to the list.
>
> * Comments are extremely thoughtful and informative.
> * Comments provide important context about the fediverse.
> * Comments focus on the application layer.
> * Comments span a wide area of social and ecological concerns in regard
> to the fediverse.
> * Comments approach specific implementations of fediverse software such
> as Mastodon.
> * Comments include valuable personal experience.
>
> I personally would like to focus on ActivityPub, without regard to
> applications and specific social concerns, and how to improve the
> protocol to allow others to run with it on the social and application level.
>
> To that end, I would like to suggest that concrete proposals be formed
> in regard to the protocol, to allow ActivityPub to be extended to
> improve the current social, ecological, and personal situation.
>
> I'll repeat the goal I emailed a couple weeks ago with this in mind:
>
> "For my take, I think a 'killer feature' [for ActivityPub] would be
> improving key exchange and verification, and potentially making public
> keys more easily available and more quickly distributed via ActivityPub
> for applications to build features on top of them (e.g. encrypted chat,
> verified user profiles, verified file sharing, maybe even software
> supply chain)."
>
> A draft of this sort of thing has been done here by Ben McGinnes at
> gnupg.org and, though I reached out to him directly and have no response
> yet, I think this is very valuable groundwork.
>
> Is anyone in this W3C group interested in this issue and collaborating
> with me on this concrete effort?
>
>
> I cannot emphasize how vital this work is with millions flooding into
> the fediverse for the first time and, for example, DM-ing over
> unencrypted channels. Those users are exposed to legal and
> police/surveillance issues but, perhaps worse, the volunteers running
> fediverse instances are exposed to extreme liability and pressure from
> government and corporate surveillance and policing.
>
>
> Cheers,
> - Sean
>
> Sean O'Brien
> Fellow, Information Society Project at Yale Law School
> Founder, Privacy Lab at Yale ISP, https://privacylab.yale.edu
>

Received on Wednesday, 7 December 2022 12:44:25 UTC