Re: [Acme] Call for adoption of draft-aaron-acme-ari-02

[Peter Thomassen <[e-mail]>]

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/