Hi Shawn, Thank you for these comments! I'm out for the rest of this week for American Thanksgiving, but will address them first thing next week.
Thanks again, Aaron On Tue, Nov 26, 2024, 00:45 Shawn Emery via Datatracker <nore...@ietf.org> wrote: > Reviewer: Shawn Emery > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any > other > last call comments. > > This standards track draft specifies an extension to the Automated > Certificate > Management Environment (ACME) service, which specifies a protocol that > allows a > client to ask an ACME server when they should renew their certificate. > > 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. > > General Comments: > > Thank you for the examples. > > Editorial Comments: > > s/to ACME/to the ACME/ > > 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 > > 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 > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
