Ilari, > On Jul 6, 2023, at 5:35 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: >> On Fri, Jun 23, 2023 at 1:44 PM Michael Sweet <msweet= >> 40msweet....@dmarc.ietf.org> wrote: >> >>> In a somewhat-related situation for printing, we have an event >>> notification interface (RFC 3996) where the printer can report back a time >>> interval (in seconds) when the client should re-contact the printer to get >>> more events. This is flexible enough to handle both printer/server load >>> and to let the client now when it should anticipate more events, i.e., the >>> printer is printing something, the event subscription is for >>> 'job-completed', and the printer can estimate when the print job will >>> complete - this is analogous to an ACME certificate's expiration/renewal >>> date/time. > > The problem is that the renew time can change, and always do so in > response to unforeseen events.
Sure, which is why you don't specify a huge interval. Think "Time-To-Live" (TTL) values in DNS records. >>> Personally, the servers I maintain use Let's Encrypt and have a weekly >>> cron job that checks whether the server's certificate needs to be renewed. >>> If the ACME server could provide a "retry after" response then my servers >>> (ACME clients) could do a better job of scheduling the next update and not >>> bug the ACME server so often... > > That is way too rarely for dealing with revocation. For that, you would > need twice a day at very least. > > The ACME client I wrote checks 8-9 times a day by default... 😳 I've been managing an admittedly small number of web/mail/etc. servers over the last 30 or so years, with encrypted services pretty much as soon as they became available. In that time I remember revoking a certificate once because I'd lost the private key somehow, but otherwise the certs I've used have only ever been renewed. If I'm provisioning an instance of some virtual server/container/whatever with an X.509 certificate, I *might* want to keep track of revocations more frequently, but otherwise I'm managing long-lived (infrastructure) services that shouldn't be going through a lot of churn. Likewise, I'm going to choose a trustworthy CA so that I (and the browser developers) don't need to worry about doing frequent revocations. I know that many security professionals get uncomfortable when a known security issue is not addressed instantly, but from a scalability and supportability standpoint we need to acknowledge that such a standard is impossible. For standards we might be able to poll the various CAs and come up with some general guidance based on the frequency of revocations vs. duration of certificates. But ultimately I'd like to see the CAs provide specific guidance (via ARI) that can be applied against local site configuration to better manage the load that ACME clients and servers have to bear. > As for load caused by that, webhooks have usability issues, but I > suspect polling would cause high load for for huge integrators. 3 > times a day with 50k certs would be ~1.7rps just from ARI. > > Hmm... How much load would ARI cause for Let's Encrypt if everyone > used ARI? Let's do back of the envelope calculation: > > - ~270M active certificates. > - ~180M are unreplaced. > - ~540M checks with 3 checks per day. > - ~6250 rps. > > Which should be fine even without CDN. So, you are estimating that 1/3 of all requests will require the issuance of a new certificate then? That's ~2000 certificates/sec which seems like a lot to me. By default those ~270M certs will expire in 3 months, so ~90M certs should be renewed/month or ~3M certs/day or ~35 certs/sec. Some percentage of the ~270M certs will also be revoked for whatever reason, but I don't think it will be 2000/sec... For reference, running OpenSSL in a loop signing cert requests as fast as possible yielded an average signing rate of ~60 ECDSA certs/sec or ~12 RSA certs/sec on my M1 Max MacBook Pro. Obviously you can run those things in parallel across multiple cores/CPUs but that will only get you so far... ________________________ Michael Sweet _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
