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, LEI 875500FXNCJPAPF3PD10. ICO register №: 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 <noreply@xxxxxxxx> 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:security@xxxxxxxxxxx"
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]
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
