Re: improving key exchange over ActivityPub

Hi Danny,

Thank you for this thoughtful and informative response. I didn't know 
the history.

Re: verification of identity, management of private keys, and wallets -

So-called Web3 technology is steaming along despite all of the issues 
FOSS folks (myself included) have worried about for many years in regard 
to key management and identity... the maxim "the perfect is the enemy of 
the good" seems to apply here.

I believe that some combination of solutions which already exist (and 
might be forked or extended) will cover the gaps in the use cases you 
describe, and that such work is out of scope for an open standard / spec.

I would expect to see a mix of tech be utilized by applications such as 
globally-distributed keyservers (which we already have), 
client-controlled wallets (e.g. browser extensions similar in UI/UX to 
MetaMask), and user trust in centralized fediverse instances (that trust 
might be misplaced or not, but look at the success of for ex. 
Protonmail).  Millions of users are currently utilizing this basket of 
tools worldwide, despite the issues you note re: cryptocurrency wallets 
etc., and I would not characterize such massive mainstream adoption of 
cryptographic technology as an "obvious failure".

Again, it seems to me out-of-scope to try to solve all identity and key 
management problems for an entire ecosystem, and it may not be our place 
to solve these issues at all.

Fediverse instances are reaching a critical mass.  Friends of mine are 
joining the fediverse for the first time and reaching tens of thousands 
of followers in *days*.  If there is an absence of a formal, 
widely-accepted spec for E2EE / PGP key exchange there are huge risks. 
Beyond the data breaches of DMs and honeypots that no doubt are already 
in-the-wild, the absence of an open standard will encourage proprietary, 
_de facto_ standards to fill the void.

I understand that, ultimately, it is important for large Mastodon 
instances to accept any standards work we do and build on it. But there 
is a lot of "new blood" in the fediverse these days -- I've had multiple 
first-time fediverse users who are talented devs asking me about E2EE.  
I expect these folks would write extensions to Mastodon and other 
applications to implement E2EE despite bottlenecks or blockers that 
might emerge with current core fediverse devs and projects.

The work you, and Ben, and likely others have done independently is 
laudable and important. I would never dream of working on any pet cipher 
or protocol -- can't we edit and consolidate existing work into a new 
proposal and at least get it published via the W3C during this critical 
time for the fediverse?

Cheers,
- Sean


Sean O'Brien
Fellow, Information Society Project at Yale Law School
Founder, Privacy Lab at Yale ISP, https://privacylab.yale.edu


On 12/7/22 07:40, Danny Moules wrote:
> 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmastodon%2Fmastodon%2Fpull%2F13820&data=05%7C01%7Csean.obrien%40yale.edu%7C8a4f933c58c6486c238108dad85046fb%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C638060136559855510%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6rQl5z7vzRiHMDk3C300Qi14ZLzwMUoNVkdx1qC51Vs%3D&reserved=0). 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

>>