Hello, IETF participants

I'm somewhat concerned about the lack of binding between an account's key,
the challenge and the certificate request. This could lead to two new
similar attacks against a user's domain.

   1. An attacker sets up an ACME server and convinces the client to use
   it, the client is then provided the attacker's ACME account on the CA's
   domain and instructs the client to setup dns-persist-01 under the
   attacker's account.
   2. An attacker sets up an ACME server and convinces the client to use
   it, the client is then provided the attacker's ACME account for the
   attacker's domain and instructs the client to setup dns-persist-01 under
   the attacker's account. This requires that the certificate authority allows
   accounts to be created under the attacker's domain e.g. creating the
   account under the domain in the Host header field as done by Let's Encrypt.

dns-01, http-01 and tls-alpn-01 all have the client's ACME account's public
key as part of the challenge so the client's account and the account the
certificate authority is issuing to must be the same.

The first attack could be prevented by having the client by making a POST
request of some sort to the account URI which allows them to verify that
their key is valid for the account.

The second attack could be prevented by the certificate authority by
verifying the account-uri is both https and on a domain they control when
verifying/offering the dns-persist-01 challenge or by restricting the
domains under which an account can be created.

Both attacks could also be prevented by having the client check that the
directory, account URI and issuer domain name have the same domain name
however this might be overly restrictive.

The issuer domain name might not be sufficient protection as the server
instructs the client as to what it should be. Given the strong security
requirements for the issuer domain names including DNSSEC but with no
requirement to resolve the domain names, maybe the authors intended to put
metadata at the issuer domain names.
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to