[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
- [Acme] Trust and security in DNS challenge valida… Joona Hoikkala
- Re: [Acme] Trust and security in DNS challenge va… Jörn Heissler
- Re: [Acme] Trust and security in DNS challenge va… Ilari Liusvaara
- Re: [Acme] Trust and security in DNS challenge va… Joona Hoikkala
- Re: [Acme] Trust and security in DNS challenge va… Sebastian Nielsen
- Re: [Acme] Trust and security in DNS challenge va… Ilari Liusvaara
- [Acme] TXT records for storing certificates in th… Jim Reid
- Re: [Acme] TXT records for storing certificates i… Sebastian Nielsen