[Acme] Re: Secdir last call review of draft-ietf-acme-ari-06

[Aaron Gable <[e-mail]>]

Hi Shawn,

The comments below are addressed in
https://github.com/aarongable/draft-acme-ari/pull/85 in the github working
copy, and will be incorporated into the next published version shortly.

Thank you for the review!
Aaron

On Tue, Nov 26, 2024 at 12:45 AM Shawn Emery via Datatracker <
[e-mail]> wrote:

> The security considerations section does exist and asserts that the base
> RFC
> for ACME, 8555, covers the various attacks and mitigations that this
> extensions
> entails.  However, this draft concedes that the client's GET request for
> renewal information MUST be unauthenticated, contrary to 8555's requirement
> that they MUST be authenticated (in which this draft discloses).  The
> justification for this position is that the renewal information is not
> confidential and allows the renewal information to be cached which will
> prevent
> aggressive clients from loading the server.  I'm concerned that exceptions
> that
> allow unauthenticated requests could lead to easier forms of DoS attacks
> (e.g.,
> bypassing the cache through tweaking the requests, no-store, etc.) against
> the
> ACME server.  This draft should describe how to mitigate against such
> attacks.
>

I have added the following text to the Security Considerations section:

"As always, servers should take measures to ensure that unauthenticated
requests for renewal information cannot result in denial-of-service
attacks. These measures might include ensuring that a renewalInfo cache
does not include superfluous request headers or query parameters in its
cache key, instituting IP-based rate limits, or other general best-practice
measures."


> General Comments:
>
> Thank you for the examples.
>
> Editorial Comments:
>
> s/to ACME/to the ACME/
>

Done.


> Are the bytes specification required in the following? (If not then I would
> suggest NEW else this may still need some rewording): OLD:
>    base64url-encoding [RFC4648] of the bytes of the keyIdentifier field
>    of certificate's Authority Key Identifier (AKI) [RFC5280] extension,
>    a literal period, and the base64url-encoding of the bytes of the DER
>    encoding of the certificate's Serial Number (without the tag and
> NEW:
>    base64url-encoding [RFC4648] of the Key Identifier field [RFC5280],
>    a literal period, and the base64url-encoding of the DER
>    encoded Serial Number field (without the tag and
>

I've simplified this sentence largely as you've suggested, but keeping the
reference to the "Authority Key Identifier extension" since it is possible
for a certificate to have two keyIdentifier fields (the second being in the
Subject Key Identifier extension).


> s/build upon/builds upon/
> s/to shed load/to shed the load/
> s/is what it is/is provided/
> s/e.g./e.g.,/g
>

Done.