#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] and timbl joined the channel; vitalyster left the channel
# nightpool[m] fr33domlover (IRC): mastodon uses LD-sigs for inbox forwarding
# nightpool[m] it will not consider an HTTP sig valid if it's not signed by the activity author
# nightpool[m] since that would defeat the whole point