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 <noreply@xxxxxxxx> 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
