From cfdc68816c25b1a4933094699e8ff625387bc38c Mon Sep 17 00:00:00 2001 From: Q Misell Date: Mon, 2 Dec 2024 13:22:03 +0100 Subject: [PATCH] address comments from SECDIR and GENART last call review --- draft-ietf-acme-onion.xml | 163 ++++++++++++++++++++++---------------- 1 file changed, 94 insertions(+), 69 deletions(-) diff --git a/draft-ietf-acme-onion.xml b/draft-ietf-acme-onion.xml index c006fba..1cd5285 100644 --- a/draft-ietf-acme-onion.xml +++ b/draft-ietf-acme-onion.xml @@ -48,8 +48,8 @@
Introduction - The Tor network has the ability to host "Onion Services" - only accessible via the Tor network. These use the ".onion" + The Tor network has the ability to host "Onion Services" only accessible via the + Tor network. These use the ".onion" Special-Use Domain Name to identify these services. These can be used as any other domain name could, but do not form part of the DNS infrastructure. The Automated Certificate Management Environment (ACME) defines challenges for @@ -76,9 +76,9 @@ defines the "dns" identifier type. This identifier type MUST be used when requesting a certificate for a ".onion" Special-Use Domain Name. The value of identifier MUST be the textual representation as defined in - . The value MAY include - subdomain labels. Version 2 addresses MUST NOT be used as these - are now considered insecure. + . + The value MAY include subdomain labels. Version 2 addresses + MUST NOT be used as these are now considered insecure. Example identifiers (linebreaks have been added for readability only): { @@ -114,7 +114,7 @@ ".onion" Special-Use Domain Names, with the modifications defined in this standard, namely , and . The ACME server SHOULD follow redirects; note that these MAY be redirects to - non ".onion" services, and the server SHOULD honour these. See + non-".onion" services, and the server SHOULD honour these. See for security considerations on why a server might not want to follow redirects.
@@ -136,7 +136,7 @@ To this end a new challenge type called "onion-csr-01" is defined, with the following fields:
type (required, string)
-
The string onion-csr-01
+
The string "onion-csr-01"
nonce (required, string)
A Base64 encoded nonce, including padding characters. It MUST contain at least 64 bits of entropy. A response generated using this nonce @@ -237,7 +237,7 @@ Content-Type: application/jose+json nor enforce CAA with any validation method. To this end, an additional field in the challenge object is defined to allow the ACME server to advertise the Ed25519 public key it will use (as per - ) to + ) to authenticate itself when retrieving the hidden service descriptor.
authKey (optional, object)
@@ -247,7 +247,7 @@ Content-Type: application/jose+json ACME servers MAY re-use public keys for re-validation of the same hidden service. There is no method to communicate to the CA that client authentication is necessary; instead the ACME server MUST attempt to calculate its CLIENT-ID as per - . + . If no auth-client line in the first layer hidden service descriptor matches the computed client-id then the server MUST assume that the hidden service does not require client authentication and proceed accordingly. @@ -257,7 +257,7 @@ Content-Type: application/jose+json This should take no more than a few minutes. This specification does not set a fixed time as changes in the operation of the Tor network can affect this propagation time in the future. ACME servers MUST NOT expire challenges before a reasonable time to allow publication of the new descriptor - - this document suggests at least 30 minutes however it is entirely up to operator preference. + it is RECOMMENDED the server allow at least 30 minutes; however it is entirely up to operator preference.
@@ -272,10 +272,10 @@ Content-Type: application/jose+json Certification Authority Authorization (CAA) ".onion" Special-Use Domain Name are not part of the DNS, and as such a variation on CAA is necessary to allow restrictions to be placed on certificate issuance. - To this end a new field is added to the second layer hidden service descriptor - + To this end a new field is added to the second layer hidden service descriptor as defined in + with the following format (defined using the notation from - ): + ): "caa" SP flags SP tag SP value NL [Any number of times] @@ -284,7 +284,7 @@ Content-Type: application/jose+json Multiple CAA records MAY be present, as is the case in the DNS. CAA records in a hidden service descriptor are to be treated the same by CAs as if they had been in the DNS for the ".onion" Special-Use Domain Name. A hidden service's second layer descriptor using CAA could look something like the following - (linebreaks have been added for readability only): + (additional linebreaks have been added for readability): create2-formats 2 single-onion-service @@ -313,6 +313,7 @@ introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3
  • b.c.onion
  • c.d.onion
  • e.c.d.onion
    • +
  • a.b.onion
    • @@ -325,14 +326,15 @@ introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3
    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 - as the CAA records are in the second layer descriptor. - A method is necessary to signal that there are CAA records present (but not reveal their contents which - - in certain circumstances - would disclose unwanted information about the hidden service operator). + In the case of a hidden service requiring client authentication the CA will be unable to read the hidden + service's CAA records without the hidden service trusting an ACME server's public key - as the CAA records are + in the second layer descriptor. A method is necessary to signal that there are CAA records present + (but not reveal their contents which - in certain circumstances - would unwantedly disclose information + about the hidden service operator). To this end a new field is added to the first layer hidden service descriptor - + with the following format (defined using the notation from - ): + ): "caa-critical" NL [At most once] @@ -349,7 +351,12 @@ introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3 still publish CAA records if its CAA record set includes "iodef", "contactemail", or "contactphone" so that this information is still publicly accessible. A hidden service operator MAY also not wish to publish a CAA record set in its service descriptor to avoid revealing information about the service operator. - If an ACME server receives a validly signed CAA record set in the finalize request it need not check the CAA + 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 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. + 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. @@ -422,14 +429,14 @@ Content-Type: application/json
    Example in-band CAA Given the following example CAA record set for 5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion - (linebreaks have been added for readability only): + (additional linebreaks have been added for readability): caa 128 issue "test.acmeforonions.org; validationmethods=onion-csr-01" caa 0 iodef "mailto:example@example.com" The following would be submitted to the ACME server's finalize endpoint - (linebreaks have been added for readability only): + (additional linebreaks have been added for readability): POST /acme/order/TOlocE8rfgo/finalize Host: example.com @@ -551,23 +558,24 @@ Content-Type: application/jose+json Special-Use Domain Names, as CAs would not be able to resolve the identifier in the DNS.
    "http-01" Challenge - The CA would follow the procedure set out in which specifies that - the CA should "Dereference the URL using an HTTP GET request". Given that ".onion" Special-Use Domain Names require - special handling to dereference, this de-referencing will fail, disallowing issuance. + In the absence of knowledge of this document a CA would follow the procedure set out in + which specifies that the CA should "Dereference the URL using an + HTTP GET request". Given that ".onion" Special-Use Domain Names require special handling to dereference, + this de-referencing will fail, disallowing issuance.
    "tls-alpn-01" Challenge - The CA would follow the procedure set out in which specifies that the - CA "resolves the domain name being validated and chooses one of the IP addresses returned for validation". - Given that ".onion" Special-Use Domain Names are not resolvable to IP addresses, this de-referencing will - fail, disallowing issuance. + In the absence of knowledge of this document a CA would follow the procedure set out in + which specifies that the CA "resolves the domain name being validated + and chooses one of the IP addresses returned for validation". Given that ".onion" Special-Use Domain Names + are not resolvable to IP addresses, this de-referencing will fail, disallowing issuance.
    "dns-01" Challenge - The CA would follow the procedure set out in which specifies that - the CA should "query for TXT records for the validation domain name". - Given that ".onion" Special-Use Domain Names are not present in the DNS infrastructure, this query will - fail, disallowing issuance. + In the absence of knowledge of this document a CA would follow the procedure set out in + which specifies that the CA should "query for TXT records for the + validation domain name". Given that ".onion" Special-Use Domain Names are not present in the DNS + infrastructure, this query will fail, disallowing issuance.
    @@ -581,19 +589,19 @@ Content-Type: application/jose+json not necessary.
    - Use of Tor for non ".onion" domains - An ACME server MUST NOT utilise Tor for the validation of non ".onion" domains, due to the - risk of exit hijacking. + Use of Tor for non-".onion" domains + An ACME server MUST NOT utilise Tor for the validation of non-".onion" domains, due to the + risk of exit hijacking .
    Redirects with "http-01" A site MAY redirect to another site when completing validation using the "http-01" challenge. - This redirect can be to either another ".onion" Special-Use Domain Name, or to a domain in the public DNS. - A site operator SHOULD consider the privacy implications of redirecting to a non ".onion" + This redirect MAY be to either another ".onion" Special-Use Domain Name, or to a domain in the public DNS. + A site operator SHOULD consider the privacy implications of redirecting to a non-".onion" site - namely that the ACME server operator will then be able to learn information about the site redirected to that they would not if accessed via a ".onion" Special-Use Domain Name, such as its IP address. If the site redirected to is on the same or an adjacent host to the ".onion" Special-Use Domain Name this reveals - information was otherwise designed to protect. + information was otherwise designed to protect. If an ACME server receives a redirect to a domain in the public DNS it MUST NOT utilise Tor to make a connection to it, due to the risk of exit hijacking.
    @@ -601,30 +609,50 @@ Content-Type: application/jose+json Security of CAA records The second layer descriptor is signed, encrypted and MACed in a way that only a party with access to the secret key of the hidden service could manipulate what is published there. For more information about this - process see . + process see .
    In-band CAA Tor directory servers are inherently untrusted entities, and as such there is no difference in the security - model for accepting CAA records directly from the ACME client or fetching them over Tor. CAA records are still - verified against the same hidden service key. + model for accepting CAA records directly from the ACME client or fetching them over Tor. 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.
    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. + and MUST NOT outsource this to a third-party service, such as by using Tor2Web.
    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 are utilised, as the IP addresses of ACME servers are generally - well-known, static, and not used for any other purpose. + 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 to unintended parties - even when features such as ECH are + utilised, as the IP addresses of ACME servers are generally well-known, static, and not used for any other + purpose. ACME clients SHOULD connect to ACME servers over the Tor network to alleviate this, preferring a hidden service endpoint if the CA provides such a service. If an ACME client requests a publicly trusted WebPKI certificate it will expose the existence of the Hidden Service publicly due to its inclusion in Certificate Transparency logs . Hidden Service - operators SHOULD consider the privacy implications of this before requesting certificates. + operators SHOULD consider the privacy implications of this before requesting WebPKI + certificates. ACME client developers SHOULD warn users about the risks of CT logged + certificates for hidden services. +
    + Avoid unnecessary certificates + Not all services will need a publicly trusted WebPKI certificate; for internal or non-public services, + operators SHOULD consider using self-signed or privately-trusted certificates that aren't + logged to certificate transparency. +
    +
    + Obfuscate subscriber information + When an ACME client is registering to an ACME server it SHOULD provide minimal or obfuscated + subscriber details to the CA such as a pseudonymous email address, if at all possible. +
    +
    + Separate ACME account keys + If a hidden service operator does not want their different hidden services to be correlated by a CA they + SHOULD use separate ACME account keys for each hidden service. +
    @@ -647,18 +675,9 @@ Content-Type: application/jose+json - - - Special Hostnames in Tor - - The Tor Project - - - - - + - Tor Rendezvous Specification - Version 3 + Tor Specifications The Tor Project @@ -674,15 +693,6 @@ Content-Type: application/jose+json - - - Tor Directory Protocol - Version 3 - - The Tor Project - - - - Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates @@ -705,6 +715,21 @@ Content-Type: application/jose+json + + + Spoiled Onions: Exposing Malicious Tor Exit Relays + + + + + + + + + 2014 + + +