Continuity; what *is* that?
Hi. It's me. I haven't written one of these in a long while, huh? Yeowch.
Anyway! Mei is a beautiful being who has successfully motivated me to sit down, start a 15 minute timer, and just spew out my thoughts on the topic of "continuity" in a blogpost. This will be extremely unstructured. Here we go!
What is "Continuity"?
So, first of all: While I do think I am quite good at naming things, I also often really don't take the time to sit down and come up with a good name for something. "Continuity" is just the first thing that came to mind when I scraped my brain for "a term that describes the ability of an actor to continue using 3rd party services, even though their home server is currently down". And that's what continuity is: It's the ability of an actor to continue using 3rd party services, even though their home server is currently down.
A couple of days ago, I noticed that for all the time I've been saying
"by the way, in polyproto, you can keep using 3rd party services, even when your home server is down"
I... have never specified this formally. And that just can't be! So I sat down and tried to think about how this should actually work, for realsies. As the time on that 15min timer approaches zero, I realize it's likely best if you just read the spec about this. But what I can do is give a good bit of meta-commentary about my thought process and stuff like that.
What do I want this to do?
Okay, sure. "You can keep using 3rd party services, even when your home server is down" is already quite a to-the-point description of what the thing is supposed to do. But it's never really this easy.
If we boil it down, what currently stops someone from just doing "continuity" without it being defined further, is certificate caching, and certificate cache information in particular. I have decided that, to distribute load across the network more evenly, you don't usually go asking home server A to give you the certificate of an actor on that home server. Instead, you ask the home server of the server you are currently talking on. This way, the home server actually responsible for the load is the home server that also has to handle that load.
But you can't just take that home server B's word for it when it gives you the certificate of an actor on home server A. The certificate you received could have long been revoked already, and the home server is currently doing some nasty impersonation stuff, exploiting this property, and the fact that your client doesn't yet know that the certificate was revoked.
Cache information is what prevents this: Home server A hands out a thing saying
"here's the ID-Cert for that actor you asked for, but this information is only valid for 60mins from now, so for messages after that, you'll have to come to me again and ask for another cache item!"
Home server B accepts that piece of information and distributes it to actors connected to it. The actors only need to contact home server A once, to get the home servers' public key. And since that is long-lived (in the order of magnitude of years), there's very little sustained load for home server A. This makes a small, low-resource home server deployment much more viable!
But it also introduces this continuity-problem. If home server A goes down, then you have a maximum of about 60 min in which you could keep using other services. And an outage can last for a day, or even a week maybe. And to make it a bit more complicated: we need to make sure that these messages are marked as not fully trusted, and that, when the home server is back online, it gets to either say "yes, these messages are all good" or "no, the user has actually revoked their cert, these messages are fake and evil and bad". And that information then also needs to arrive at all the clients that participated in this conversation.
And defining all these delicate security aspects and how exactly communication around this subject works is precisely what we need the "continuity" section in the protocol for.
This actually took like, 25 minutes, instead of the 15 minutes I wanted it to take, but oh well. I am also very sorry if this blog post makes no sense at all or is hard to understand; though I did warn you of that in the beginning :3