Add security considerations about checking ACME 'url'

[ounsworth]

Corey Bonnell pointed out that because this scheme will result in ACME clients creating new accounts more frequently than they do now, there is greater potential for MitM attacks where an attacker intercepts ACME new-account reqs and replaces the account key with their own; then they have full control of the ACME account.

The only real prevention of this is for CAs to be diligent about checking the "url" ACME JWT header and make sure that it matches the CA / ACME server's public URL.

https://www.rfc-editor.org/rfc/rfc8555.html#section-6.4.1

[vanbroup]

If we assume that the client validates the TLS certificate of the ACME server and both the client and server are not compromised, the attacker needs to compromise the TLS connection, or poisen the DNS lookup for the auto discovery as described in #16.

[vanbroup]

The attack here is that an attacker can spoof the CAA record of the subscribers domain.

[vanbroup]

@CBonnell can you have another look at this issue, if you feel that this needs to be included in the implementation/security considerations can you create a pull request for this or let us know if it can be closed.

We would like to incorporate this for the next IETF meeting, the deadline for submissions is July 8, 2024.

[CBonnell]

@vanbroup assign this issue to me, I'll work on making some language this week.

[CBonnell]

I forgot that ACME uses Key Authorizations that mix in a thumbprint of the account key in the challenge token. So even if an ACME server does not follow the guidance in section 6.4 of RFC 8555 in regard to verification of the request URL, it would not be possible for a malicious ACME "proxy" to compel a client to prepare a DCV challenge that would enable the malicious proxy to request a certificate with its own key in the CSR after DCV has completed.

As such, I think this can be closed.