Skip to content
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

Recommended algorithm may lead to renewals outside of suggested window #71

Closed
mholt opened this issue May 3, 2024 · 2 comments
Closed

Comments

@mholt
Copy link

mholt commented May 3, 2024

Maybe this is OK, since the window is only a suggestion, but I noticed that this algorithm in section 4.2:

  1. Select a uniform random time within the suggested window.
  2. If the selected time is in the past, attempt renewal immediately.
  3. Otherwise, if the client can schedule itself to attempt renewal at exactly the selected time, do so.
  4. Otherwise, if the selected time is before the next time that the client would wake up normally, attempt renewal immediately.
  5. Otherwise, sleep until the next normal wake time, re-check ARI, and return to Step 1.

can result in clients renewing before the renewal window.

Let's say the client wakes up once every 24 hours (that's very infrequent, but for the purposes of this discussion let's go with this). It wakes up 23 hours before the start of the renewal window, and 23.1 hours before the selected time (it happened to be toward the very beginning of the window). Step 2 is out because it's in the future. Let's say step 3 is out too, since it can't schedule itself. Step 4 then says to perform renewal immediately, which is still 23 hours before the renewal window even starts.

Is that acceptable? Or should the client wait until it's in the renewal window (but then miss the selected time, albeit just a little bit in this case)?

My code so far looks something like cutoff := cert.ari.SelectedTime.Add(-cfg.certCache.options.RenewCheckInterval). So, of course, if cert.ari.SelectedTime is near the beginning of the window, and cfg.certCache.options.RenewCheckInterval is any amount large, the resulting cutoff is likely to be before the start of the window.

You know I'm in favor of earlier renewals 🙂 , but I did want to seek clarification on this.

@aarongable
Copy link
Owner

  1. Yes, the situation you describe is acceptable -- if it wasn't, I wouldn't have specified it.
  2. Note that the algorithm is merely RECOMMENDED. If you believe you have a better algorithm, then implementing that is perfectly acceptable.

We could amend the algorithm to say "If the next time that the client would wake up normally is within the renewal window, do step 5", but that extra layer of complexity didn't seem worthwhile to me.

@mholt
Copy link
Author

mholt commented May 3, 2024

Okay, thanks for clarifying. I'll roll with that then 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants