Re: HTTP Signature CG report

Hi Christine,


The approach you present (Allowing the client application to sign requests)
has well known security flaws and allows for any attacker to DOS and
prevent posts from being created for any other user on their server due to
ID exhaustion. Therefore I do not recommend this scheme be used for any
multiuser server (where multiple users share one domain name).

(And obviously, for single user servers the client and the server are
probably in the same trust boundary)

On Wed, Feb 7, 2024, 8:29 AM Cristiano Longo <
cristianolongo@opendatahacklab.org> wrote:

>
> On 06/02/24 11:04, Marcus Rohrmoser wrote:
>
>
> Hi Ryan and nightpool,
>
> thanks for taking initiative to improve the specifications mandaratorily used in today's fediverse. The previous word of mouth culture is IMO a big obstacle to interoperability.
>
> On Mon, 5 Feb 2024 11:34:07 -0800
> Ryan Barrett <public@ryanb.org> <public@ryanb.org> wrote:
>
>
> We've started collecting candidate requirements inhttps://github.com/swicg/activitypub-webfinger/issues . Feel free to
> comment or add your own proposals!
>
>
> While I somehow feel the appeal of cryptography, I miss the hard facts about it's benefits here.
>
> We have the tls umbrella, so there should be a certain trust in that the other side is who they pretend to be. Like in "the same private key as last time", right?
>
> Introducing mechanisms (in application layer) where the communicating party (the user) has no hold of the private key, still requires full trust to the holder i.e. the server application and the underlying storage system and their operators.
>
> What do we gain? We still have to trust the application.
>
> Please writing this report take into consideration that the signature may
> be produced client-side. I produced a proof of concept of an activity pub
> server where signature is performed client side:
> https://www.opendatahacklab.org/lap_src, sources at
> https://github.com/cristianolongoodhl/LittleActivityPub.
>
>
> Given that, we just could block based on self-declared incoming actor id + ssl validity, save complexity and not have to resort on volatile standard drafts.
>
> What am I missing?
>
> Marcus
>
>
>