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

[John Mattsson <[e-mail]>]

On 25 Mar 2015, at 13:24, Jonathan Rudenberg <[e-mail]<mailto:[e-mail]>> wrote:


On Mar 25, 2015, at 9:35 AM, John Mattsson <[e-mail]<mailto:[e-mail]>> wrote:

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.

Section 11.1.1 of the Baseline Requirements allows this:

Thanks for pointing this out.

6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or

I would state that making a change to an online web page (http://) does not prove control of the FQDN, it only proves being on-path...

7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.

The current status quo is that many CAs allow “put this meta tag or text file on the HTTP server” as a challenge, which is *less* secure than the proposed DVSNI and Simple HTTPS challenge methods.

Yes, but that CAs is doing something does not mean that IETF should standardise or recommend something. I think DVSNI and Simple HTTPS challenge methods are fundamentally different. In DVSNI and “put this meta tag or text file on the HTTP server” the root of trust is being on-path. In the Simple HTTPS challenge the root of trust is the HTTPS certificate.

If the only automated challenge method available is DNS, this puts a *huge* damper on the usability of the system.

I would prefer dropping DVSNI and only use Simple HTTPS and DNS. That would damper the usability somewhat, but I think it’s worth it. But in the end it boils done to what presenting a domain certificate is supposed to prove...

 The point that DNS configuration damper the usability indicates that somebody should look at automatic DNS management as well….

Do you have any concrete modifications or alternatives to the DVSNI validation method that would improve the security?

I don’t think it’s theoretically possible to hinder on-path attackers in a system that uses being on-path as the root of trust.

Do you have the same complaint about the Simple HTTPS validation method?

No, see above.


Jonathan

John