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

From: John Mattsson <[email-masked]>
Date: Wed, 25 Mar 2015 16:35:01 +0000

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Mar 2015 17:56:16 +0000

> 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.

But you are already giving them complete control of your environment, if they decide to do something bad.  From a security viewpoint, if you're running on someone else's host, how can you prevent it?

---

From: Jonathan Rudenberg <[email-masked]>
Date: Wed, 25 Mar 2015 11:24:31 -0700

> On Mar 25, 2015, at 9:35 AM, John Mattsson <[email-masked]> wrote:
> 
> Hi,
> 

Section 11.1.1 of the Baseline Requirements allows this:

> 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
> 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.

If the only automated challenge method available is DNS, this puts a *huge* damper on the usability of the system. Do you have any concrete modifications or alternatives to the DVSNI validation method that would improve the security? Do you have the same complaint about the Simple HTTPS validation method?

Jonathan

---

From: John Mattsson <[email-masked]>
Date: Wed, 25 Mar 2015 19:42:25 +0000

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

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

Hi,

- Security:

Thanks for pointing this out.

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...

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

---

From: Jonathan Rudenberg <[email-masked]>
Date: Wed, 25 Mar 2015 12:50:30 -0700

> On Mar 25, 2015, at 12:42 PM, John Mattsson <[email-masked]> wrote:
> 
>> On 25 Mar 2015, at 13:24, Jonathan Rudenberg <[email-masked]> wrote:

I’m not clear on your definition of “on-path” and distinction between the two challenges. Both Simple HTTPS and DVSNI allow anyone who can respond to TCP connections to a domain to request a certificate for it.

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

Sure, but practically speaking this isn’t going to happen any time soon.

Jonathan

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 25 Mar 2015 17:15:27 -0500

On Wed, Mar 25, 2015 at 2:42 PM, John Mattsson
<[email-masked]> wrote:
> 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.
>
>

This seems like a big deal, no? That is, since SNI is one of the few
things not protected in the TLS handshake, it does seem spoofable. If
there's not something I'm missing, it seems like the proposal should
just drop DVSNI altogether.

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 25 Mar 2015 15:21:45 -0700

An attacker who fully controls the network is explicitly not part of the
threat model for any Domain Validation. None of the available techniques
for DV, whether they involve fetching a file, sending an email, or doing
a TLS handshake can fully mitigate a network attacker.

---

From: Jonathan Rudenberg <[email-masked]>
Date: Wed, 25 Mar 2015 15:23:33 -0700

> On Mar 25, 2015, at 3:15 PM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 

An active MITM attacker could compromise the Simple HTTPS validation as well, this is not a threat model that any current DV challenges address.

Jonathan

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Mar 2015 22:25:14 +0000

> This seems like a big deal, no? That is, since SNI is one of the few things not
> protected in the TLS handshake, it does seem spoofable. If there's not
> something I'm missing, it seems like the proposal should just drop DVSNI
> altogether.

The SNI is protected (part of the message final MAC's) but it is not encrypted.

---

From: Bernd Eckenfels <[email-masked]>
Date: Wed, 25 Mar 2015 23:34:50 +0100

DVSNI has the same protection level than cleartext tokens (or
challenge emails). It is an opportunistic way of automatically verifying
the domain. I dont think the TLS part in there is meant to add any
protection (how should it, if the cert is not trusted).

Besides scanning from different locations to reduce the risk and of
course not using the method when the idendity is already protected with
a key there is not much ACME can do in a automated CA scenario.

This is pretty similiar to SSH's TOFU.

Having said that I was quite suprised that a new method was suggested.
It IMHO mainly adds bloat.

Gruss
Bernd

Am Wed, 25 Mar 2015 17:15:27 -0500
schrieb Joseph Lorenzo Hall <[email-masked]>:

> > 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

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 25 Mar 2015 17:36:14 -0500

Cool, thanks for clarifying, all.

---

From: James Kasten <[email-masked]>
Date: Wed, 25 Mar 2015 15:48:49 -0700

> It IMHO mainly adds bloat.

It proves authoritative access over the server.  Changing the certificate
requires modifying the server configuration.  SimpleHTTP/S is vulnerable to
attackers who have filesystem access (PHP script etc) but don't necessarily
have authoritative permission over the server process itself.

DVSNI also doesn't require an HTTP server to perform the challenge.

On Wed, Mar 25, 2015 at 3:36 PM, Joseph Lorenzo Hall <[email-masked]> wrote:

> things not
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Mar 2015 10:40:53 -0500

> a TLS handshake can fully mitigate a network attacker.

It has been suggested that some measure of network control can be
mitigated by originating the validation requests from multiple network
locations.  That would be down to CA policy though.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Mar 2015 11:01:13 -0500

> locations.  That would be down to CA policy though.

It is called 'running a CA'.

That type of conversation is best left to CABForum and discussions
with your friendly neighborhood auditors.