search

aarongable / draft-acme-ari

Internet Draft for the Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension
Other
3 stars 7 forks source link

When to poll again if server does not send Retry-After? #69

Open mholt opened 2 months ago

mholt commented 2 months ago

Section 4.2 says:

The server SHOULD include a Retry-After header indicating the polling interval that the ACME server recommends. Conforming clients SHOULD query the renewalInfo URL again after the Retry-After period has passed, as the server may provide a different suggestedWindow.

Because of SHOULD instead of MUST, what should clients do for poll timing if the Retry-After header is omitted?

The only potentially relevant advice I can find is at the end of the section:

If the client receives no response or a malformed response (e.g. an end timestamp which is equal to or precedes the start timestamp), it SHOULD make its own determination of when to renew the certificate, and MAY retry the renewalInfo request with appropriate exponential backoff behavior.

But this seems to be related more to error handling and not a successful response without a Retry-After header. If we were to do exponential backoff as the norm (i.e. with successful responses), we'd likely end up hammering the endpoint at first and then potentially missing the window later!

Should we poll every... hour? Day? 2 hours? 10 minutes? I guess I'm looking for what to do in practice here. Thanks

mholt commented 2 months ago

Thinking on this more, I wonder if a default poll interval of some ratio until the start of the suggestedWindow would make sense, since in general, we have no idea what timescales we'll be operating on.

If the system wakes every minute, you don't want to poll every time if the remaining certificate lifetime is on the order of weeks or months.

If the certificate lifetime is on the order of hours, you probably want to poll more often.

aarongable commented 1 month ago

I don't think this level of detail is worth specifying at the protocol level. Clients have been implementing polling, and servers have been implementing rate-limiting, since time immemorial. There are many good ways to do it, and many bad ways to do it, and I don't think it is within the purview of this small document to try to solve them.