Re: HTTP Signature CG report

It definitely would! We already have a pretty substantial list of goals for
the report, along with a solid set of other non-goals that we'd love to dig
into but regrettably have to postpone to keep the scope manageable, so
sadly I don't think we'll have time to add this.
https://github.com/swicg/activitypub-http-signature/issues

It definitely seems worth digging into though! Cristiano, we'd love it if
you and/or others were interested in digging into it, in either a follow-up
to this report or maybe a full report on its own! I'm sure Evan and the
other chairs would be happy to talk and help with details.

On Thu, Feb 8, 2024 at 3:59 AM Cristiano Longo <
cristianolongo@opendatahacklab.org> wrote:

> I'm solely suggesting that investigating the client-side signature
> approach, also with reporting the security issue provided by nightpool,
> would make the report more exhaustive.
>
> CL
> On 07/02/24 18:03, Dmitri Zagidulin wrote:
>
> > I think we're probably significantly off-topic for the thread in
> question then,
>
> Yeah, hehe, agreed, sorry bout that.
>
>
>
> On Wed, Feb 7, 2024 at 12:03 PM nightpool <eg1290@gmail.com> wrote:
>
>> I think we're probably significantly off-topic for the thread in question
>> then, which is about a CG report on the current state of HTTP Signatures
>> within the fediverse. The scheme you're proposing would require two keys
>> (one for the actor to sign client-side, and another for the server to sign
>> to verify that the origin https://example.com has been used correctly),
>> or a delegated key with some kind of ID prefix (i.e. some way for
>> example.com to say that mallory's key is valid only for URIs starting
>> with example.com/@mallory/).
>>
>> On Wed, Feb 7, 2024 at 11:57 AM Dmitri Zagidulin <dzagidulin@gmail.com>
>> wrote:
>>
>>> Also, let me back up and try to address this on a slightly more abstract
>>> level.
>>> Server-side signing is a TEMPORARY state of affairs. Like.. it's not
>>> good, it's just an artifact of tech limitation (lack of good client-side
>>> key management options) at the time.
>>> And it's definitely not the "only secure method" that the previous
>>> discussion is implying, but exactly the opposite (something we have to put
>>> up with currently, but will try to move away from).
>>>
>>> If current server implementations don't handle client-side signing
>>> correctly, that's fine, we'll have to fix that (and painfully wait till the
>>> fixes propagate through the ecosystem).
>>> If there's something in the AP protocol that's adding to the confusion /
>>> making client-side signing harder, we'll fix the protocol.
>>>
>>> (Hopefully my answers make more sense in that context.)
>>>
>>>
>>>
>>>
>>> On Wed, Feb 7, 2024 at 11:49 AM Dmitri Zagidulin <dzagidulin@gmail.com>
>>> wrote:
>>>
>>>> > There is no way a receiving server can tell that
>>>> example.com/posts/123 is "supposed to" be bar's ID to sign, instead of
>>>> foo's.
>>>>
>>>> And why's that a problem? (also, let's switch to the usual Alice for
>>>> legit post author and Mallory for the attacker).
>>>> If Alice creates a post and client-side signs it, and then Mallory
>>>> makes a post with the same ID and client-side signs it and sends it to
>>>> another server -- you're right that the receiving server doesn't know who
>>>> the post is "supposed to" belong to.
>>>> However, that doesn't really matter. People who don't subscribe to
>>>> Mallory won't see her posts (they'd only see Alice's posts). Is that not
>>>> the case?
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 7, 2024 at 11:46 AM nightpool <eg1290@gmail.com> wrote:
>>>>
>>>>> I'm talking about the ID for the activity itself. The Activity is
>>>>> attributedTo example.com/users/foo, but it purports to shares an id (
>>>>> example.com/posts/123) with a legitimate post made by
>>>>> example.com/users/bar. There is no way a receiving server can tell
>>>>> that example.com/posts/123 is "supposed to" be bar's ID to sign,
>>>>> instead of foo's.
>>>>>
>>>>> On Wed, Feb 7, 2024 at 11:43 AM Dmitri Zagidulin <dzagidulin@gmail.com>
>>>>> 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")
>>>>>>
>>>>>> Wait, that's not how client signing works tho. The whole point of
>>>>>> client signing is that nobody else can sign with the same ID (cause they
>>>>>> don't have your keys).
>>>>>>
>>>>>>
>>>>>>

-- 
https://snarfed.org/