Subject: [Acme] Exposed rate limits

From: Niklas Keller <[email-masked]>
Date: Mon, 21 Mar 2016 09:28:30 +0100

Morning,

I added a PR exposing potential rate limits to clients. Rate limits can be
used to show warnings to the user, e.g. when certificate issuance is
limited to 5 certificates per 7 days and you already issued 3. A single
client can't count these, because they may be on different servers using
different clients.

https://github.com/ietf-wg-acme/acme/pull/104

Best Regards,
Niklas Keller

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 09:53:33 +0100

adding to this some parts of rate limits should be maybe made a bit clearer
if not already (e.g. if you have multiple different domains in a SAN which
will get the count, just the CN? or all of them?
also it would be nice to add a command that gives you the ability to check
the limits before even thinking of creating a cert.

2016-03-21 9:28 GMT+01:00 Niklas Keller <[email-masked]>:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Niklas Keller <[email-masked]>
Date: Mon, 21 Mar 2016 10:34:41 +0100

2016-03-21 9:53 GMT+01:00 Philipp Junghannß <[email-masked]>:

> adding to this some parts of rate limits should be maybe made a bit
> clearer if not already (e.g. if you have multiple different domains in a
> SAN which will get the count, just the CN? or all of them?

That's totally true, didn't think about that. I'll update the PR.

---

From: "J.C. Jones" <[email-masked]>
Date: Mon, 21 Mar 2016 15:28:18 -0700

Niklas,

When there are multiple kinds of rate limits affecting the current
transaction, would you imagine that these headers should only
illustrate the most restrictive? For example, Let's Encrypt has both
"per-FQDN" and "per-Registered Domain" limits active now, each with a
different state.

I'd like to avoid a meta-language inside the headers, certainly. I'd
also like whatever we add to be useful. Perhaps there should be a
"RateLimit-Name" header to define which limit is being described?

- J.C.

On Mon, Mar 21, 2016 at 2:34 AM, Niklas Keller <[email-masked]> wrote:
>> adding to this some parts of rate limits should be maybe made a bit clearer if not already (e.g. if you have multiple different domains in a SAN which will get the count, just the CN? or all of them?
>> also it would be nice to add a command that gives you the ability to check the limits before even thinking of creating a cert.
>
>

---

From: Niklas Keller <[email-masked]>
Date: Mon, 21 Mar 2016 23:45:15 +0100

> "per-FQDN" and "per-Registered Domain" limits active now, each with a

Didn't have time to think about it yet, but having only the most
restrictive limit sounds good.

> "RateLimit-Name" header to define which limit is being described?

Will it be possible to standardize all names? Other CAs may use other rate
limits. So should `RateLimit-Name` be a code or a human readable message?

Regards, Niklas

---

From: "J.C. Jones" <[email-masked]>
Date: Mon, 21 Mar 2016 15:51:39 -0700

> limits. So should `RateLimit-Name` be a code or a human readable message?

My guess is that getting an exhaustive list of rate limits would be
difficult, and that implementing CAs may want to adjust these values
quickly outside IETF.

It's probably good to leave flexibility it in, if we can. Further thought:
Instead of or in addition to a name, there could be a URI to a description
or help document.

Cheers,

- J.C.

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 23:55:41 +0100

well My idea would be:
display the most restrictive by default.
add option to list all.
about the code vs readable message I would think of a hybrid approach.
apply a code and a message.
the code coule be used so the client if it knows it that it could e.g.
translate it into different languges etc. and the embedded message copes
with all clients that dont know the code yet, also add a code for "other"
which can be used for stuff that doesnt have a code yet

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 21 Mar 2016 16:00:50 -0700

A couple thoughts:

- Probably the "reset" field should be named something else, and should
only be provided when a rate limit was actually hit. Let's Encrypt uses
a sliding window (aka leaky bucket) for rate limits, so reset time is
not well-defined for requests that didn't hit a limit.

- One of the goals of ACME is to be applicable to paid CAs. The rate
limit concept may map rather cleanly onto a notion, in a paid CA, of a
number of certificates already paid for on an account. Perhaps
"Requests-Remaining" would be a more general name?

On 03/21/2016 03:51 PM, J.C. Jones wrote:
> On Mon, Mar 21, 2016 at 3:45 PM, Niklas Keller <[email-masked]
> <mailto:[email-masked]>> wrote:
> It's probably good to leave flexibility it in, if we can. Further
> thought: Instead of or in addition to a name, there could be a URI to
> a description or help document.
>
> Cheers,
>
> - J.C.
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Mar 2016 19:05:17 -0400

There could be many different issue related signals: Payment required
for instance.

What is an abusive rate may depend on the source. Some large ISPs
might generate a number of requests that might be considered a DoS
attack coming from a residential IP.

On Mon, Mar 21, 2016 at 6:45 PM, Niklas Keller <[email-masked]> wrote:
> Didn't have time to think about it yet, but having only the most restrictive
> limit sounds good.
>
>>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 21 Mar 2016 16:11:01 -0700

> attack coming from a residential IP.
Agreed. How we manage this within Let's Encrypt is to have a set of rate
limit overrides to deal with legitimate heavy users.

---

From: Philipp Junghannß <[email-masked]>
Date: Tue, 22 Mar 2016 00:22:45 +0100

wait a sec you *do* have overrides for LE? it was iirc stated often enough
that nothing can be done about rate limits...

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 21 Mar 2016 16:54:58 -0700

[off-topic a bit]

On 03/21/2016 04:22 PM, Philipp Junghannß wrote:
> wait a sec you *do* have overrides for LE? it was iirc stated often
> enough that nothing can be done about rate limits...
We don't do one-off fixes for folks who have exceeded a weekly rate
limit, but for hosting providers that are doing a large integration, we
have a request process. We process these on a very sporadic basis, so
it's only a useful solution for long-term integrations.