Hi Aaron,
The pull request LGTM. Thank you for the update.
Regards,
Shawn.
--
On 12/6/24 12:23 PM, Aaron Gable wrote:
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
<nore...@ietf.org> 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.
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
