Re: HTTP Signature CG report

> 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).
>>>>>
>>>>>
>>>>>