Skip to main content

Telechat Review of draft-ietf-acme-onion-05
review-ietf-acme-onion-05-dnsdir-telechat-brown-2025-01-05-00

Request Review of draft-ietf-acme-onion
Requested revision No specific revision (document currently at 07)
Type Telechat Review
Team DNS Directorate (dnsdir)
Deadline 2025-01-07
Requested 2024-12-06
Authors Q Misell
I-D last updated 2025-01-05
Completed reviews Dnsdir Early review of -02 by Peter van Dijk (diff)
Opsdir Early review of -02 by Qin Wu (diff)
Secdir Early review of -02 by Derrell Piper (diff)
Dnsdir Last Call review of -04 by Peter van Dijk (diff)
Genart Last Call review of -04 by Dale R. Worley (diff)
Secdir Last Call review of -04 by Derrell Piper (diff)
Secdir Telechat review of -05 by Derrell Piper (diff)
Dnsdir Telechat review of -05 by Matt Brown (diff)
Opsdir Telechat review of -05 by Qin Wu (diff)
Assignment Reviewer Matt Brown
State Completed
Request Telechat review on draft-ietf-acme-onion by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/l96umj4FJYaxKOcZy11TFordZrA
Reviewed revision 05 (document currently at 07)
Result Ready w/nits
Completed 2025-01-05
review-ietf-acme-onion-05-dnsdir-telechat-brown-2025-01-05-00
Hi,

I've reviewed the -05 revision of this draft, noting that the -02 and -04
revisions were already reviewed by another DNSDIR member and were in good
shape. I consider this draft ready, with one nit discussed below.

The draft specifies how subdomains of the ".onion" Special-Use Domain Name are
to be treated by the ACME protocol, including defining a new ACME verification
type. Given the existing special-use designation of the .onion. name I see
minimal DNS considerations from this draft. I have not given any particular
consideration to the overall security implications of impact on the ACME
specification of this draft - leaving that to other, more qualified
directorates and reviewers.

The most DNS relevant consideration in this draft from my reading is the re-use
of the CAA DNS RR presentation format in section 6 for the purposes of allowing
the CAA data (up until now fetched via DNS only) to be provided to a CA via the
TOR protocol.

My nit here is the re-use of a DNS RR presentation format through redefinition
using its constituent fields, rather than by  reference to the existing format
definition in RFC8659.

Redefining the presentation format in this way creates a synchronization risk
if/when any future updates to the CAA RR that modify its presentation format
occur.

It would be clearer if the draft simply referred to the use of the CAA RR
presentation format directly (leaving its definition in RFC8659 only) thereby
allowing any future updates to it to flow through automatically; or if that is
not desired, explicitly note why the presentation format is being redefined
here (and perhaps consider using a different presentation format in that case
in order to avoid confusion).

The consequences of a future change to the CAA RR not updating this draft would
be felt only by .onion names and the CA ecosystem rather than the DNS, so from
a DNSDIR perspective I list this as a nit rather than a blocking issue.