Thank you for your review and comments! These all seem like good suggestions - I will incorporate them as appropriate. ------------------------------
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 21 Nov 2024 at 03:57, Dale Worley via Datatracker <nore...@ietf.org> wrote: > Reviewer: Dale Worley > Review result: Ready with Nits > > 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 > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > 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:secur...@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", <https://spec.torproject.org/rend-spec/index.html>. > > [tor-dir-spec-v3] > The Tor Project, "Tor Directory Protocol - Version 3", > <https://spec.torproject.org/dir-spec/index.html>. > > 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] > > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
