#social 2019-02-28
2019-02-28 UTC
tantek, xmpp-social, dansup and vitalyster joined the channel
# 
cjslep[m] fr33domlover I feel like we are talking past each other on socialhub
# cjslep[m] sent a long message: cjslep[m]_2019-02-28_14:21:13.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/uDmNLEEGabNwEAgqTClrkUAa>
# fr33domlover Hey cjslep[m] ! Yeah maybe it's because I never described my use case there in detail
# fr33domlover cjslep[m], what I'm doing is defining (and implementing) a way to use object capabilities with activities, so that some activities are sent along with authorization. And I want to use object capabilities, not necessarily OCAP-LD, just generally OCAP. So (1) in OCAP-LD you sign a JSON document called "capability delegation". In my case, if you produce such a delegation, you're the only one who will be
# fr33domlover looking at it, and you already keep it in your DB, so in practice you don't need to create and sign that JSON document. However you do need to pass *some* token to the issuee, and I *do* want this token signed. At first I didn't think of that, but following your comments, I realized that token can happily be signed or encrypted
# fr33domlover cjslep[m], (2) The issue about rotation isn't specific to my usage, it's a side thing, but if you like I can still explain. Basically the reason I mentioned rotation is that I needed a way to be sure that even if keys get rotated, it doesn't get in the way of establishing trust. Anyway, I'll write a description of that soon and then if I missed some easier solution, you or someone else will show me :)
# fr33domlover cjslep[m], (2b) I mean if you have 1 key and you replace it, the old one isn't available. I agree you can make a new one and leave the old one availabl, I just mean right now Mastodon etc. uses a single key. Anyway, Spritely stuff is just future/theory right now, I'm assuming plain HTTPS fediverse as my starting point
# fr33domlover cjslep[m], (3) Suppose you give user john@doe.com edit access to your file. Suppose for a moment, the way you identify joe is by his public key, using HTTP signatures. Now imagine the server at doe.com shuts down, and the domain is expired. Now I, an attacker, rent doe.com, create a user named joe and try to make malicious commits to your file. How does your server know I'm not the original john@doe.com?
# fr33domlover One way, it will notice my signature is invalid. This works but it relies on me keeping the same public key, unable to rotate it. And if I do rotate it, using blind key rotation, your server will see a new key, accept it, and voila I can edit your file. When using a secret access token that joe must possess, this prevents my attack, because I don't have the token joe had, and I can't make malicious edits
# fr33domlover while pretending to be him. And if this token *isn't* secret, then we need some *other* way to trust joe@doe.com, such as servers having per-server secret tokens, or using permanent non-rotating signing keys. This too, sorry if my wording is confusing, I'll write in more detail soon I hope
# fr33domlover In other words, when actor keys are allowed to do blind rotation, the only identification we're left with is the domain name, which has that scenario where your domain name expires and I rent it and pretend to be you etc.
# fr33domlover So there needs to be some extra bit to prevent that, by somehow identifying that scenario
# cjslep[m] Gotcha, thanks for taking the time to explain all this.
# fr33domlover cjslep[m], did my explanation help? I was worried it would only add confusion ^_^
# fr33domlover I suppose this domain reuse thing isn't a problem so far because nobody has done it on the fediverse
# fr33domlover (It requires that an instance goes down, domain rented by different person, and all that happens secretly before anyone notices the events, and before people block that instance it has enough time to send garbage etc.)
# fr33domlover (So it's an unlikely scenario, but I don't like the thought that it's possible)
# cjslep[m] Yes it helps. I think I agree with you that using LDS with a "blind" rotation is a security vulnerability.
# cjslep[m] The obvious and low effort answer being... Don't use blind rotation.
# fr33domlover cjslep[m], that's true, but I do want to support blind rotation. I want to try using the OCAP tokens to solve this problem, at least for the activities that will be requiring OCAPs. Either using secret tokens, or using public tokens + permanent per-server keys
# cjslep[m] Why solve blind key rotation as part of ForgeFed, and not as a separate general effort?
# cjslep[m] I guess that's what you're doing. :)
# fr33domlover cjslep[m], I do want the solution to be independent of ForgeFed :) I just mean I want to get started with something, publish my idea, and then we can happily pick up the rotation stuff separately from forge stuff
# cjslep[m] Of course. I appreciate you taking the time to explain it to me. From here on out I'm just going to await your solution. :)
# fr33domlover cjslep[m], thanks for all your comments!!! They have been so so helpful to me
# cjslep[m] I am glad you feel that way -- when making them, sometimes I feel more dumb than helpful.
# fr33domlover cjslep[m], Nope they really are helpful :) I guess if I use public tokens, (1) avoid the need to protect them, if token leaks then no harm (2) if the issuer remembers to which user@host it gave the token and uses HTTP signatures to verify activities, this is secure, except for that weird domain-reuse scenario I described. So maybe instead of using secret tokens, I can use public ones in ForgeFed, and
# fr33domlover leave the weird domain reuse issue to be handled separately for the whle fediverse not just forges
# dlongley the above situation is solved with DIDs (long term stable IDs that aren't "rented", are cryptographically bound, and don't change hands) ... but that does mean adopting a new tech.
# fr33domlover cwebber2, will DID come to Spritely? ^_^
# fr33domlover dlongley, thanks for mentioning this!
# dlongley sure; so you delegate to a DID instead of a specific key ... and then the controller of that DID can rotate as much as they want
# dlongley of course, if you rotate out the delegation key or if the delegation chain grows (given that you've permitted this) and a key in that chain is rotated, it will be broken, but this may be considered a feature not a bug
# dlongley so the expectation is that delegation keys are expected to have different life cycle properties than invocation keys.
# fr33domlover dlongley, I agree, the challenges I mentioned above are about invocation signatures
# dlongley yeah (which is the common use case)
# fr33domlover cwebber2, it's ok I'm not in a hurry to explore this :)
# fr33domlover Just wondering for the future
# dlongley well, it's definitely a use case for the standards we're trying to build :)