Thanks to Rich, Melinda and Peter for voicing your opinion to adopt this draft. We would like it if a few more people would read this draft and state whether you think it should be adopted (or not). After the positive response in Vienna we were a little surprised to see so few responses here.
For your ACME WG Chairs, Deb On Wed, Jun 29, 2022 at 1:24 PM Peter Thomassen <pe...@desec.io> wrote: > Hi Aaron, > > On 6/18/22 01:48, Aaron Gable wrote: > > You can find prior discussion in these threads: > > - > https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/ < > https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/>, > the very original proposal, which discusses are variety of motivations and > alternate implementations > > - > https://mailarchive.ietf.org/arch/msg/acme/UMRzzS6yh-D6ViwjYt0fgx213qY/ < > https://mailarchive.ietf.org/arch/msg/acme/UMRzzS6yh-D6ViwjYt0fgx213qY/>, > my revival of the idea, which addresses some of the concerns in the > original thread > > Thank you for these pointers. > > > It's not my experience that RFCs in this space dedicate significant > space in their text to discussing alternative designs, but if others would > like to see a section like that added to the draft I'm happy to oblige. > > I don't think much argument is needed, but I think it would be helpful to > add at least one compelling use case to the introduction that hints at the > insufficiency of the obvious alternatives that would come to mind (that is, > client-side jittering). Perhaps like this (drop-in for the last paragraph): > > Being able to indicate to the client a period in which the issuing CA > suggests renewal would allow proactive smearing of load (as client-side > jittering would), but also enable dynamic changes to the certificate > validity period, such as in the event of mass-revocation of a large > number of certificates, and help restore normality after such an event > by having clients quickly redistribute from the sudden renewal spike to > a moreuniform renewal schedule. > > This document specifies a mechanism by which ACME servers may provide > suggestedrenewal windows to ACME clients. > > > Yes, of course clients could simply implement smearing on their own. But > they have little motivation to do so -- there's no standard documenting how > they should do so, and it's statistically rare that any one out of hundreds > of millions of clients is the one affected by a given load spike. They can > just retry and be fine. Having a standard for this provides a template or > framework to encourage clients to all implement this in the same way. > > I'm afraid there will be little motivation for updating legacy clients, > regardless of whether the update would bring client-side ARI support (as > documented by a standard) or client-side smearing (which could also be > standardized). > > It's the typical upgrade-with-backwards-compatibility problem: Unless ACME > servers would REQUIRE clients to support ARI (which would be a breaking > change), clients might not upgrade. If they do, chances are that they have > a proper update process, in which case they'd receive any update, > regardless of which solution is standardized. > > So, regarding client-side deployability, I think that ARI has no advantage > over client-side smearing. > > > Suppose that a CA revokes and replaces 100M certificates in a single > day. Suppose further that, as you suggest, they smear their validity > periods by 1%, meaning that clients will try to renew somewhere between 59 > and 61 days after the incident. How many renewal cycles will it take for > that 100M-cert-tall load spike to flatten back out into the whole 60 days > of smooth issuance it previously covered? > > Convinced! > > > Suppose that a CA suffers an incident and knows that they will have to > revoke and replace 100M certificates in the next 24 hours. They could > configure ARI to give all clients a renewal window in the past, encouraging > every client that checks in to immediately renew their certificate, > minimizing the real-world impact of a mass revocation event. And then they > go immediately to the case described above, to prevent additional fallout. > > That's very convincing, too. I think it would help if the intro gave a > glimpse of these use cases. > > > I hope this provides more insight into why we've gone this direction > with the design, and why the draft is important! > > Surely, thanks! I hope I did not hold up the draft with my critical > questions :-) Thank you for being open for discussion. > > I support adoption. > > Best, > Peter > > -- > https://desec.io/ >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
