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

[Deb Cooley <[e-mail]>]

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 <[e-mail]> 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/
>