[Acme] High level comments on draft-barnes-acme (the GitHub version)

[John Mattsson <[e-mail]>]

Hi,

Some high level comments on draft-barnes-acme (the GitHub version)


- Security:
The security of this seems to need some serious rethinking. The “Domain Validation with Server Name Indication” challenge seems totally nonsecure, allowing ANY on-path attacker to get certificates issued. I think this challenge is unacceptable for certificate issuance and I think it should be removed. Just because I let Amazon, Microsoft, Google or any other cloud provider run my web server does not mean I give them the right to request certificates for my domain.

And no, the account key pair and recovery token does not help:
- Most domains will not have any registration with an ACME CA, allowing an on-path attacker to get certificates from any ACME CA.
- And if a domain has registered with ACME CA1, the attacker can just use ACME CA2 instead. This not only allows the on-path attacker to get certificates for the domain, it also allows the attacker to highjack the registration with ACME CA1 as the ultimate recovery mechanism is “Recertification by another CA + PoP of that key”.

We cannot standardize a solution were the security depends on domains registering with all CAs supporting ACME, and standardizing something that lets on-path attackers request certificates does more harm than good. I hope that I am missing something...


- Validation methods:
The Introduction mentions three methods for domain validation:
 - Put a CA-provided challenge at a specific place on the web server.
 - Put a CA-provided challenge at a DNS location corresponding to the target domain.
 - Receive CA challenge at a (hopefully) administrator-controlled e-mail address
   corresponding to the domain and then respond to it on the CA's web page.

But the e-mail method does not seem to be described at all in the draft and the DNS method is not listed in the table in the Section “Identifier Validation Challenges”.


- Scope:
The current name and draft suggest the broad scope of certificate management for HTTPS servers. And in “Deployment Model and Operator and Operator Experience” the ACME client is clearly a newly deployed HTTPS server. I think this is the right scope, but as I stated earlier I think this scope must include certificate import.

If certificate import is not in scope, then the work is not the currently stated certificate management for HTTPS servers, then it’s just Interface to Certificate Authority (I2CA), and in that case I think the ACME client will not and should not be the HTTPS server. A web server is definitely the wrong place to store the recovery token, and for virtualized cloud based web servers my view is that they in many cases should not even have an ACME account key pair.


Cheers,
John

———————————————————————
John Mattsson
Ericsson IETF Security Coordinator 
Senior Researcher, Security