[Acme] Trust and security in DNS challenge validation automation

Joona Hoikkala <joona.hoikkala@eff.org> Tue, 16 January 2018 10:12 UTC

Return-Path: <joona.hoikkala@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA91300CE for <acme@ietfa.amsl.com>; Tue, 16 Jan 2018 02:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.031
X-Spam-Level:
X-Spam-Status: No, score=-7.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM4JO1mYlM8k for <acme@ietfa.amsl.com>; Tue, 16 Jan 2018 02:12:33 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADFA12FB55 for <acme@ietf.org>; Tue, 16 Jan 2018 02:12:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=DWsm2HgRx68M/u8uYh/G8htCKslOnroFXCv4Xy0HTV8=; b=w14GmaNlLt3r12WElaU580PaxRIyFcLFwkBzR9eYYYD5cCyt5l4kDryxzTy+LEy6qnsgaR/uSuXqpgUxhDHAUS0CnEwepQDx3xV9BdIC3gyzbGlh4rN22byXYJhyGBnRXnKJfGGI7t8iv2TJEEAz/nS2NlkkN/qKFYWD2XTQmbI=;
Received: ; Tue, 16 Jan 2018 02:12:00 -0800
To: acme@ietf.org
From: Joona Hoikkala <joona.hoikkala@eff.org>
Message-ID: <1a6f7bfb-d6dc-bd1a-fcb5-ec78ec4497cf@eff.org>
Date: Tue, 16 Jan 2018 12:12:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------08712D66091F13E304B0D083"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/VlsdaUYbO743yygUQp5KN0RBMbM>
Subject: [Acme] Trust and security in DNS challenge validation automation
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 10:17:55 -0000

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