Apologies for the delay, vacation and then a work conference distracted me. Replies inline:
On Mon, May 30, 2022 at 8:54 AM Peter Thomassen <[email protected]> wrote: > Hello, > > I have a hard time deciding whether the proposal is a good idea or not, > because the document does not contain sufficient information for me to make > up my mind. In particular, I only see a problem statement and a solution > proposal, but no reasoning on alternatives and why the proposal is the way > to go. > > This may be partly because I'm new to the list, but nevertheless, I think > a document in general should present some arguments for its existence. (But > I'm also happy with pointers to earlier messages on the list.) > You can find prior discussion in these threads: - 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/, my revival of the idea, which addresses some of the concerns in the original thread 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. In particular, Section 1 states that clients renew certificates either > > a) at specific intervals, or > b) a specific amount of time before the certificate's expiration, or > c) when some percentage of the validity period has passed. > > I buy the argument that this causes problems with load spikes. > > > Cases b) and c) may be alleviated more easily (in particular: with no > client-side complexity, no protocol change, and no extra GET requests to > the server), by smearing the certificate validity period, at issuance, > randomly across 1%, e.g. between 100% and 101%, or between 99% and 100%. > > As a result, renewals would be attempted at random times of the day if the > validity is at least ~3 months. In general, that is achieved if the > smearing is designed to cover a full day. (This is assuming common web PKI > validity periods. For very short-lived (~days) certificates, one would have > to discuss whether such smearing would be too large a fraction of the total > period.) > I think that assuming that current common web PKI validity periods will persist into the future is not a great assumption. We already have things like ACME STAR (https://datatracker.ietf.org/doc/rfc8739/) encouraging certs with lifetimes on the order of days or hours. Renewal timing could be randomized on the client side as well. This would > also cover case a). While requiring a client upgrade, the ARI proposal does > so as well. If it is expected that clients will be sufficiently > upgrade-able in order to get ARI deployed, then what is the reasoning that > the same thing can't be achieved with client-side smearing? > 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 know that some clients do randomize, and it seems like that has not been > successful, otherwise we wouldn't have this draft. Is that the case? Why? > (And we should we have higher hopes for succeeding with ARI support on the > client side?) > > > IMHO, the proposal demands rather high cost (client-side change, > server-side change, protocol change, extra requests). Having some arguments > why it is worth it will make it much easier to decide whether it should be > adopted or not. > But most of the above points are just minor details. At the end of the day, randomization (whether on the server side or the client side) can only accomplish so much -- and that amount is not enough. 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? Random smearing cannot quickly fix a spike that large, while ARI could *immediately* start asking a small fraction of clients to renew, restoring normal issuance patterns within a single renewal cycle. 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. Both of these are important use-cases for ARI that have been discussed on this list previously, and which are not able to be served simply by randomly jittering validity periods or renewal times. I hope this provides more insight into why we've gone this direction with the design, and why the draft is important! Thanks, Aaron > Best, > Peter > > > On 5/24/22 13:30, Deb Cooley wrote: > > There has been some discussion of draft-aaron-acme-ari-02 on the mail > list, at working group meetings, and the technical concerns have been > addressed. > > > > Should the ACME WG adopt “Automated Certificate Management Environment > (ACME) Renewal Information (ARI) Extension” in draft-aaron-acme-ari-02? > > > > Please reply to this message within the next two weeks, by Tuesday, 7 > June 2022 to voice your support or opposition to adoption. > > > > On behalf of the ACME WG Chairs, > > Deb Cooley > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > -- > https://desec.io/ > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
