[Last-Call] Dnsdir telechat review of draft-ietf-acme-onion-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Matt Brown
Review result: Ready with Nits

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.


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux