#social 2019-04-23

2019-04-23 UTC
bblfish, Guest84, vitalyster, xmpp-social and KjetilK joined the channel
#
fr33domlover
o/
#
fr33domlover
When doing inbox forwarding, should a server copy the HTTP sig it received, or sign with its own signature, discarding the one it received?
#
fr33domlover
(I guess use original because otherwise servers can fake stuff authored by other servers?)
timbl and bblfish joined the channel
#
cjslep[m]
Http signatures are HTTP request/response specific. New requests, new signatures.
KjetilK joined the channel
#
cjslep[m]
I personally don't like the pattern of tying a users private key to sign specific HTTP requests with an HTTP signature. But that's the world we find ourselves in.
#
cjslep[m]
Also I don't know whether Mastodon/Pleroma simply forward the HTTP Signature or not. But a receiving server really should just refetch the original Activity from the originating server which then gets a valid HTTP signature from the originating actor.
bblfish joined the channel
#
cjslep[m]
The problem with forwarding an HTTP signature is, for ex: what if the Date header is signed? You can't forward the signature without forging a fake Date header now. The naive approach of writing Application level logic to introspect such headers to determine whether to forward or not is a rather... crude and awful (to put it nicely) band aid.
#
cjslep[m]
So just don't forward. Let recipients of the forwarded Activity re-ask the authoritative server in order to get an HTTP signature from the authoritative user. Defensive programming and all.
#
cjslep[m]
Granted, I still think this is a pretty bad situation to be in the first place, and would rather get something like content addressing to eliminate the problem to begin with.
#
fr33domlover
cjslep[m], thank you for the thoughts! Mastodon docs say it requires the signature key to match the activity actor; but I'm unsure whether that applies to inbox forwarding too. Either way the date header is not a problem; Mastodon has a 12-hour margin, which is enough for reasonably available servers. Hmmmm it's funny I haven't thought of this issue at all until now
#
fr33domlover
The problem with making a new signature is indeed that you must GET the activity from the origin server
#
fr33domlover
Which is kind of sad, you get the whole JSON object just to fetch it all over again from the origin server
#
cjslep[m]
Date is just an example. Don't get hung up on it, just don't forward it. Causes a lot of headaches and unnecessary code. If you need another more insidious example to continue with why it's a bad idea, the '(request-target)' option would include the path of the original request, which definitely won't match the forwarded one. Going down this path is not a great idea. So if Mastodon can get away with it, great for them. It's just not a choice I would
#
cjslep[m]
have made.
#
cjslep[m]
And yes the whole refetch thing is a PITA. I agree.
#
fr33domlover
Hmmm interesting
#
fr33domlover
So, I send a comment on some note hosted on a different server, not my own
#
fr33domlover
And that note's author, and all commenters etc. that might be, say, in some tragic case, 1000 people
#
fr33domlover
That server will inbox-forward my comment, and very soon after, ~1000 requests for that comment will hit my server :P
#
fr33domlover
I guess Mastodon, Pleroma etc. might get away by not signing (request-target)
#
fr33domlover
Which, I admit sounds so much simpler than PITAfully fetching activities
#
fr33domlover
nightpool[m], do you know by chance what Mastodon does with HTTPsigs when it does inbox forwarding? (if does inbox forwarding at all)
#
fr33domlover
(Which I guess it could live without, if all actor collections are public etc.)
#
fr33domlover
Another silly idea is to chain the (request-target)s, that's trivial when collections aren't supposed to contain other collections, but it's not very useful if the fediverse as a whole doesn't support it
#
fr33domlover
thinks macaroons :P
#
cjslep[m]
Probably. It's a hack around LD-Sigs being... suboptimal. But it'd be using HTTP signatures in a way that is not intended
#
fr33domlover
Actually, since the Signature header itself isn't signed... hmmm nah I must be missing something
#
fr33domlover
Like, I thought for a moment, what if you rename the Signature header, and place the (request-target) value in a custom header, then put your new signature in the Signature header? :P
#
fr33domlover
Ah the problem would be that the host of the key wouldn't match the host of the activity
#
cjslep[m]
What is instead needed is a side channel or protocol that says: Here is content, here is how to verify it is the tampered with (verifiable, ex a hash), here is a public key owned by actor A (look-up-able), here is their verifiable signature of this untampered content (pub key verifiable). Which content addressing gets very close to.
#
cjslep[m]
It is not* tampered with
#
fr33domlover
cjslep[m], we can do that with HTTP sigs too if we drop (request-target). I mean, unless I'm missing something, the (request-target) and Host headers being signed serves as a proof that the author *intended* to send us the activity, and it wasn't just forwarded by someone else. The question I'm asking myself is, how to preserve that proof without breaking the HTP sig? I guess the obvious idea is to have a
#
fr33domlover
special HTTP header "authorizing" another server to do the delivery, but indeed that's an extension. That being said, if I use it, it's harmless, while allowing me to avoid those annoying GETs :p
#
fr33domlover
There's incompatibility there: AP allows inbox forwarding, but HTTP sigs don't (unless you give up the ability to be sure the activity was meant by the author to be sent to you)
#
fr33domlover
Technically it's possible I get tons of activities in my inbox due to being listed in their BCC or BTO
#
fr33domlover
My only way to be sure they were intended for me, as I can't see those fields, is the signature on Host and (request-target)
#
fr33domlover
Otherwise, anyone can send me any activity and I drown in spam
#
fr33domlover
(Well, I can drown in spam either way, but this is a really easy way to end up drowning)
#
cjslep[m]
I don't think spam makes for any strong argument one way or the other about HTTP signatures.
#
fr33domlover
cjslep[m], well, it could be message integrity or whatever they're meant to provide ^_^
#
fr33domlover
I mean, specifically what the signing of Host and (request-header) is meant to provide
#
fr33domlover
*request-target
Po-chiangChao[m] joined the channel