I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-acme-onion-04 Reviewer: Dale R. Worley Review Date: 2024-11-20 IETF LC End Date: 2024-11-26 IESG Telechat date: not known Summary: I have not assessed the technical details of how these changes integrate with the rest of the ACME protocols, not being well-versed in ACME. (I expect that the WG will do that adequately.) Similarly, I have not assessed the security properties of this protocol. (I expect the SecDir review will do that adequately.) I have assessed the quality of the exposition. This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: 2. Identifier [...] as defined in Part .onion of [tor-address-spec]. [...] For consistency, I think you want to say 'Part ".onion" of'. 3.2. New "onion-csr-01" Challenge type (required, string) The string onion-csr-01 Comparing RFC 8555 sections 8.3 and 8.4 suggests you want: type (required, string) The string "onion-csr-01". 5. ACME over hidden services [...] this document suggests at least 30 minutes however it is entirely up to operator preference. There are various places in the document which seem to be wanting BCP 14 language. For instance, here it seems it would be clearer to call out [...] this document RECOMMENDS at least 30 minutes however it is entirely up to operator preference. A number of uses of "can" seem like they should be "MAY". Actually, RECOMMENDS isn't proper BCP 14; you probably need something like [...] it is RECOMMENDED the server allow at least 30 minutes; however it is entirely up to operator preference. 6. Certification Authority Authorization (CAA) To this end a new field is added to the second layer hidden service descriptor Part "Second layer plaintext format" of [tor-rend-spec-v3] with [...] There seems to be a word missing between "hidden service descriptor" and "Part". There seems to be a similar issue with the reference to tor-rend-spec-v3 in section 6.3. A hidden service's second layer descriptor using CAA could look something like the following (linebreaks have been added for readability only): create2-formats 2 single-onion-service caa 128 issue "test.acmeforonions.org;validationmethods=onion-csr-01" caa 0 iodef "mailto:security@example.com" introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3 KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs= ... Taking this text literally, that means that the "second layer descriptor" starts create2-formats 2single-onion-servicecaa 128 issue "test.acmeforonions.org;validationmethods=onion-csr-01" [...] but I doubt you meant that. I suspect you mean that the linebreak and subsequence whitespace at the end of the "introduction-point" line is to be ignored but the other linebreaks are intended to be part of the descriptor. To say that requires revising the wording. There are also a couple of situations like this in section 6.4.2. 6.1. Relevant Resource Record Set but these do not: It might be worth adding "a.b.onion" to that list to show that an intermediate label can't be elided in order to match "a.onion". 6.3. Preventing mis-issuance by unknown CAs In the case of a hidden service requiring client authentication it is impossible to read them without the hidden service trusting a ACME server's public key [...] In re "it is impossible to read them", it is not clear who is trying to read what. You probably want to make that clear. Also, "a ACME" should be "an ACME". would disclose unwanted information about the hidden service operator "unwanted information" is incorrect, really. Probably you mean "unwantedly disclose information" or perhaps "disclose unwantedly information". (Check that with the Editor.) 6.4. Alternative in-band presentation of CAA If an ACME server receives a validly signed CAA record set in the finalize request it need not check the CAA set in the hidden service descriptor and can proceed with issuance on the basis of the client provided CAA record set only. An ACME server MAY ignore the client provided record set, and is free to always fetch the record set from the service descriptor. I think you want some "MAY"s in this paragraph to explicitly call out the various permissions. Something like If an ACME server receives a validly signed CAA record set in the finalize request it MAY proceed with issuance on the basis of the client provided CAA record set only without without checking the CAA set in the hidden service. Alternatively, an ACME server MAY ignore the client provided record set and fetch the record set from the service descriptor. In any case, the server always MAY fetch the record set from the service descriptor. 8.2.1. "http-01" Challenge The CA would follow the procedure set out in Section 8.3 of [RFC8555] [...] Under what circumstances "would" the CA follow this procedure? The remainder of the paragraph suggests that this is in some sort of error situation, but none of the context is supplied here. (It appears that the last paragraph of appendix A may be the intended context.) Sections 8.2.2 and 8.2.3 have similar issues. 8.4. Use of Tor for non ".onion" domains It seems that this should be 'Use of Tor for non-".onion" domains', but ask the Editor. There are other instances of this construction elsewhere. [...] due to the risk of exit hijacking. You probably want to explain or provide a reference for "exit hijacking" as the term doesn't seem to be used in RFCs and Google doesn't turn up any references other than the acme-onion documents. 8.7. In-band CAA CAA records are still verified against the same hidden service key. "still" probably isn't the right word, as there doesn't seem to be a time-sequence involved. Also, the referent of "the same" is unclear. Do you mean "there is no difference in the security model between accepting CAA records directly from the ACME client and fetching them over Tor; the CAA records are verified using the same hidden service key in either case"? 8.8. Access of the Tor network The ACME server MUST make its own connection to the hidden service via the Tor network, and MUST NOT outsource this, such as by using Tor2Web. This should have more detail, since any connection to any part of the Internet "is outsourced" at some level of the protocol stack. I suspect that what is meant is that some particular activity is here described as "making a connection to the hidden service via the Tor network" and that activity MUST be done within the ACME server; what that activity is should have its proper technical name given here. I suspect the needed concept is "the server's endpoint of the XXX layer connection stack MUST be within the server itself, and not outsourced to a less-trusted facility". 8.9. Anonymity of the ACME client ACME clients requesting certificates for ".onion" Special-Use Domain Names can inadvertently expose the existence of a hidden service on the host requesting certificates to unintended parties - even when features such as ECH [I-D.ietf-tls-esni] are utilised, as the IP addresses of ACME servers are generally well-known, static, and not used for any other purpose. Given the following paragraph, I suspect that this applies only when the request is done not over Tor. Also, moving "to unintended parties" makes the sentence clearer, so I suggest ACME clients requesting certificates for ".onion" Special-Use Domain Names not over the Tor network can inadvertently expose to unintended parties the existence of a hidden service on the host requesting certificates [...] -- Hidden Service operators SHOULD consider the privacy implications of this before requesting certificates. I think you should add to this sentence "before requesting WebPKI certificates", as there are other certificate requests (like ACME .onion requests) to which seems not to apply. Then again, perhaps there are additional types of certificate requests to which this does apply. Indeed, looking at the abstract of RFC 9162, it talks of TLS server certificates rather than WebPKI -- are these the same or different from WebPKI certificates? Clarification is in order. 9.1. Normative References [tor-rend-spec-v3] The Tor Project, "Tor Rendezvous Specification - Version 3", . [tor-dir-spec-v3] The Tor Project, "Tor Directory Protocol - Version 3", . Both of these references go not to documents, but to a set of hyperlinked pages. I much dislike this sort of reference, especially as a normative reference, because it leaves ill-defined what the reference *is*. It also requires using the web site's tools to search the "document", and the actual behavior of those tools is unknown. And looking for the reference in section 6, "Part "Second layer plaintext format" of [tor-rend-spec-v3]", I notice that the sidebar outline of index.html does *not* include an item "Second layer plaintext format". Instead, I strongly recommend you give the URL of an actual document. There clearly is one, as the "print" icon will return a document. In that document, I can search for, e.g. "Second layer plaintext format", using my tools. [END]