-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keeping the client in sync #173
Comments
What if the looking up key is in TBs queue? It happens when the registration and the key lookup are in the same epoch or when we support the key change operation.
You mean the expected time the next epoch will be published, right?
Queuing seems better to me. My main consideration is how can we put this flow into the library. I think most of these have to be done from the application level (but we can temporarily ignore this for now). |
Very good point; this needs some thought. Initial ideas could be,
Yes; well, it would be |
The downside is that every request other than monitoring (mostly key lookup) has to be queued until the client catches up with the latest epoch, which may cause some (noticeable) latency for the users. This probably needs to be measured by testing and benchmarks.
I'm not sure if the client can trust the Then, do we really need to make monitoring happen before every other operation? |
Not necessarily. You can continue doing lookups in the most recently verified epoch.
It's just a heuristic to help clients stay in sync. Trust will come with auditing. |
The problem happens when the users change their keys frequently.
But then how can the client report when the attack happens, since there is no proof of the issued (Actually, I have proposed to use |
EDIT: To clarify, @arlolra, are you suggesting that the server include a timestamp in the STR, or not? If not, I agree with Huy here. An abstract OTOH, I think that an epoch interval together with an actual timestamp are a better heuristic for clients. Then, if a client sees |
Yes, the timestamp would still be in the STR. We could add a third condition that the interval returned be strictly monotonically decreasing, until the next epoch. But, let's not get too bogged down on this heuristic thing. I mentioned it only as a helpful way to keep the client closer to the actual deadline. |
Ok, to recap, so far we've identified that,
Keep it coming :) |
This doesn't make sense, since the client should trust the |
Here are something I have in mind towards this issue:
|
This proposal addresses #144, #119, and various other things we've been calling the time skew issue. It's basically a summary of what was discussed in the hangout today.
The main idea being that the epoch increases in lock step with monitoring, and all subsequent requests happen in epoch, which avoids the edge cases where a request may happen in an epoch that has yet to be verified. Consequently, only monitoring updates the saved STR and the API for looking up in the latest epoch should be eliminated.
The first thing the client should do at startup is monitor, sending the epoch it knows about so that the server only needs to return STRs in the interval. The server can also send the time until the next epoch, for the client to set a timer. The client should be sure to check that the time is less than or equal to that attested to in the latest STR.
There's a bit of trickiness around the registration request (since it also needs to happen in epoch, as we said above). If the client is yet to register, the monitoring request at startup should be checking proof of absence. Since registration has to happen in the latest epoch, if the server receives a request to register in an outdated epoch, it should return an error, and give the client a chance to defer / re-request with exponential backoff. Alternatively, the client can set a
monitoring
flag totrue
and prematurely queue other requests until that's done.Thoughts?
The text was updated successfully, but these errors were encountered: