Re: [Acme] Trust and security in DNS challenge validation automation

["Sebastian Nielsen" <[e-mail]>]

I don't see a reason to do a ready-baked solution for privilege management, as every enviroment is different. Let people handle security for themselves.

If you want to have more security over your DNS, you could have it that you have a static private key on the web server/application server, and then the same key to create certificates from your DNS server.
Then you have a script that publishes the certificate. You could ACTUALLY publish the certificate in the DNS zone as a TXT.
Each TXT record may only contain up to 255 characters, but you could easily split it up to multiple records.

And from your web server/application server, you download the certificate periodically.
Note that certificates are already public per definition, so its no danger to make certificates public.

Thus if your web server/application server gets compromised, your DNS zone isn't compromised.

-----Ursprungligt meddelande-----
Från: Acme [mailto:[e-mail]] För Joona Hoikkala
Skickat: den 16 januari 2018 11:12
Till: [e-mail]
Ämne: [Acme] Trust and security in DNS challenge validation automation


While ACME tries to promote automation of the challenge validation, the
landscape of said automation looks rather grim. DNS server software and
service providers rarely provide means to limit the privileges of
credentials used to update DNS zones.

This leads to users being forced to use and save their credentials often
equipped with inflated privileges to every machine that needs to acquire
certificates using DNS challenges, effectively meaning that when one of
such machines gets compromised so does the whole DNS zone, or multiple
zones in some cases.

The issue can be somewhat alleviated by using a separate validation zone
that the user can point CNAME records towards to for the CA to follow.
The problem however stays the same, if the credentials get compromised
the malicious user is again able to issue certificates for all the
domains pointing CNAMEs towards the validation zone in question. This
information is also easily acquired by going through CT logs and trying
to resolve the validation subdomains for each CN and SAN domain.

The only cloud DNS service provider I know that actually allows creation
of subdomains with separate credentials is Microsoft Azure. Some
providers make it possible to create new credentials and to assign a
subdelegate zone for these credentials, and pointing the CNAME there.
These solutions are a bit better, but still largely outside of the reach
of a typical user.

To fix these issues I wrote a small piece of server software (
https://github.com/joohoi/acme-dns/ ) that can be used to fix the issues
described above, but using it in large scale would raise new questions
about trust in general and the role of the service provider in the whole
chain. After all, this software isn't designed to be deployed by every
user of DNS challenge.

Would a reasonable solution be to deploy something similar to the
ACME-DNS software closer to the CA?

--
Joona Hoikkala