Re: HTTP Signature CG report

On 07/02/24 17:40, nightpool wrote:
> If clients have custody of keys, then `foo@example.com` could wait for 
> `bar@example.com` to make a post, and then sign an activity with the 
> same ID (e.g. "example.com/posts/102930 
> <http://example.com/posts/102930>") and send it to all of the 
> instances that bar has followers at. This would mean that nobody would 
> be able to see bar's posts (if foo wins the race condition for 
> distributing it, which in practice is often easy if foo has a local 
> account on example.com <http://example.com>). The vulnerability is 
> much worse if your implementation is using predictable IDs, but it 
> exists conceptually any time that an origin is shared between multiple 
> users. For this reason, actor keys in ActivityPub used for HTTP 
> Signatures or LDSigs cannot be given to the user. There is no way that 
> a local server could avoid this vulnerability through validation, 
> since the client (if it has access to the HTTP Signature private key) 
> could always bypass their server to talk to other federated servers 
> directly. There is no way to avoid this vulnerability without 1) 
> making keys server-private or 2) throwing out HTTP Signatures entirely 
> and resolving every incoming activity.
>
I mumbled a lot about this. I came to the conclusion that a malicious 
server can perform this attack as well, so it doesn't matter who hold 
keys and who sign requests. A non-malicious server could prevent this 
attack just enforcing that IDs of activities created by a user falls 
into a user specific namespace so that server users cannot interfeer 
with each other.
> Regarding whether "sharing private keys with a server" is a security 
> fault, that is a claim that has no basis in the ActivityPub trust 
> model, which considers your actor ID authoritative using the rules 
> defined for its resolution. There are other types of URIs, like DIDs, 
> that could provide the types of guarantees you're looking for, but if 
> you're using a normal HTTPs URL, then your server /by definition/ is 
> going to be the authority on what your public key is, so there's no 
> way to avoid trusting it without an entirely different cryptographic 
> approach than any deployed so far within the fediverse.
nice point
>
>
> On Wed, Feb 7, 2024 at 11:19 AM Dmitri Zagidulin 
> <dzagidulin@gmail.com> wrote:
>
>     > The approach you present (Allowing the client application to
>     sign requests) has well known security flaws
>
>     Yeah, I agree with Cristiano, it's only a security flaw if
>     implemented wrongly on the server side. Client-side signing is
>     what we should try and move the whole ecosystem to.
>
>     On Wed, Feb 7, 2024 at 10:11 AM Cristiano Longo
>     <cristianolongo@opendatahacklab.org> wrote:
>
>         Hi nightpool, may you provide some reference about this
>         security faults? However I consider sharing my private key
>         with a server a security fault as well.
>
>         On 07/02/24 15:55, nightpool wrote:
>>         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>  <mailto:public@ryanb.org>  wrote:
>>>
>>>>             We've started collecting candidate requirements in
>>>>             https://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
>>>