When my ACME client finish its run, it normally has one valid nonce at the end that will never be used. I imagine a drop_nonce ACME API call similar to new_nonce. That would strike out from the internal nonce table of the boulder the actual nonce, making the table's use more efficient (less table overflow to drop old, unused nonces). Would that make any sense? Do you have any statistics related to nonce generation - dropping unused nonces?
Somehow differently: Does the boulder already have "no operation" API call that requires nonce to protect against replay attack, but does not provide new nonce?
I doubt there would be much benefit in supporting an explicit "drop nonce" action. They don't really live long enough to make it worth it and every existing call that uses a nonce is already effectively dropping it because they can't be re-used.
I agree with @rmbolger. I don't see a serious risk from a hanging, short-lived nonce. Can you describe a scenario where this would pose a measurable threat?
It is not for any possible threat, it is rather for performance, lowering the load on the nonce management code.
On the meantime I had another idea. Normally the last API call is to download the certificate in the chain of API calls. What about if that API call would not automatically create a new nonce?
You can find the nonce code here: https://github.com/letsencrypt/boulder/blob/main/nonce/nonce.go Looks like much thought has gone into it already, but I'm not speaking "Go", so no idea if it can be improved. In any case, I'm pretty sure nonces are ephemeral seeing the following text:
The MaxUsed value determines how long a generated nonce can be used before it is forgotten.
Who says a client stops there? Maybe a client is configured to issue multiple certificates using the same ACME connection.
There's nothing today, but it's a reasonable concern! Fortunately, nonces are extremely cheap: They only ever exist in-memory, and most of the time don't require any cross-datacenter network traffic.
The nonce cleanup process cleans up both used and unused nonces: We need to track used nonces to ensure they're only used once! So disposing of a nonce as unused wouldn't help. If we could avoid generating the nonce in the first place, it's potential there's some savings. Ultimately that's very low on our priority list, as there's a great deal of more expensive things to optimize first.
Normally, but not guaranteed. That has the potential to break client implementations.
I think an alternative option would be allowing certain endpoints - including that one - to accept a "No-Nonce" header, which would suppress generating a new nonce. Nonces are ridiculously cheap and short-lived though.