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

[Aaron Gable <[e-mail]>]

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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
>
> --
> https://desec.io/
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>