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
