Original text:
9.4.  The controls on issuance enabled by ACME are focused on validating that a certificate applicant controls the identifier he claims. Before issuing a certificate, however, there are many other checks operators of ACME-based CAs will need to keep in mind when configuring their services.  For example: <del> It is advisable to perform DNS queries via TCP to mitigate DNS forgery attacks over UDP </del>  <del> [[ TODO: Other operational considerations ]] </del>  <del> 10.1. </del>  In many cases, TLS-based services are deployed on hosted platforms that use the Server Name Indication (SNI) TLS extension to the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-02"). <del> 10.2. </del>  An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names.  Because the security of such

Reviewer comments:
Server side request forgery (SSRF) is possible through ACME when using http-01 because an attacker can use HTTP 3xx redirects to make the ACME verifier server perform an HTTP GET of any URL. Additionally, Boulder helpfully includes (part) of the HTTP body in the detail field of Unauthorized errors. In theory, an HTTP GET of any URL is idempotent and won't actually affect anything. But, if the ACME server returns any part of the HTTP body in error messages (like Boulder does), an attacker could potentially read sensitive data from internal servers. Typical targets for SSRF would be metadata services (like 169.254.169.254 in AWS or OpenStack), any not publicly exposed HTTP interface of the server's stack (like the HTTP API of the RabbitMQ management plugin), or any other internal HTTP server on the server's private network. Perhaps the IETF ACME protocol spec should acknowledge SSRF in its Security Considerations? One recommendation could be to not allow connections to internal network addresses. However, if someone wanted to use ACME for a private intranet CA, correct firewalling like that is much harder. The spec could also discourage including the HTTP body in an Unauthorized error's detail field. Or at least don't include the HTTP body if a redirect was followed. Also, this is mostly mitigated by the actual implementation of Let's Encrypt and Boulder. Notably, only 128 characters (maxResponseSize) of the HTTP body are . And it doesn't seem possible to get Let's Encrypt to access HTTP servers on any port other than 80 or 443, even with a port number specified in the redirect URL, which limits what an attacker could access. (I reported this privately to EMAIL before creating this GitHub issue. This is not an issue for Let's Encrypt.)
Thanks for reporting! Can you post this to the EMAIL mailing list for further discusion? Not everyone who participates in the WG follows the GitHub repo.

Revised text:
9.4. <ins> Server-Side Request Forgery (SSRF) attacks can arise when an attacker can cause a server to perform HTTP requests to an attacker-chosen URL.  In the ACME HTTP challenge validation process, the ACME server performs an HTTP GET request to a URL in which the attacker can choose the domain.  This request is made before the server has verified that the client controls the domain, so any client can cause a query to any domain. Some server implementations include information from the validation server's response (in order to facilitate debugging).  Such implementations enable an attacker to extract this information from any web server that is accessible to the ACME server, even if it is not accessible to the ACME client. The risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path. Nonetheless, in order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. 9.5. </ins> The controls on issuance enabled by ACME are focused on validating that a certificate applicant controls the identifier he claims. Before issuing a certificate, however, there are many other checks operators of ACME-based CAs will need to keep in mind when configuring their services.  For example:  <ins> 10.1. </ins>  <ins> As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates.  Servers SHOULD verify DNSSEC when it is available for a domain.  When DNSSEC is not available, servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. </ins>  <ins> 10.2. </ins> In many cases, TLS-based services are deployed on hosted platforms that use the Server Name Indication (SNI) TLS extension to the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-02").  <ins> 10.3. </ins> An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names.  Because the security of such