Skip to main content

Last Call Review of draft-ietf-acme-ari-06
review-ietf-acme-ari-06-secdir-lc-emery-2024-11-26-00

Request Review of draft-ietf-acme-ari
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-12-06
Requested 2024-11-22
Authors Aaron Gable
I-D last updated 2024-11-26
Completed reviews Tsvart Last Call review of -06 by Michael Tüxen (diff)
Dnsdir Last Call review of -06 by Geoff Huston (diff)
Secdir Last Call review of -06 by Shawn M Emery (diff)
Genart Last Call review of -07 by Susan Hares
Dnsdir Telechat review of -07 by Geoff Huston
Secdir Telechat review of -07 by Shawn M Emery
Assignment Reviewer Shawn M Emery
State Completed
Request Last Call review on draft-ietf-acme-ari by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/9RjjXrZKEnQo6XOyLOyYkiPpWYc
Reviewed revision 06 (document currently at 07)
Result Has issues
Completed 2024-11-26
review-ietf-acme-ari-06-secdir-lc-emery-2024-11-26-00
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