Re: [Acme] Assisted-DNS challenge type

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 23 January 2018 07:09 UTC

Return-Path: <ilariliusvaara@welho.com>
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 CEE7212DA17 for <acme@ietfa.amsl.com>; Mon, 22 Jan 2018 23:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 D8zLsDC9iDsW for <acme@ietfa.amsl.com>; Mon, 22 Jan 2018 23:09:39 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D1E12D953 for <acme@ietf.org>; Mon, 22 Jan 2018 23:09:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 16E3E46EE9; Tue, 23 Jan 2018 09:09:37 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Qg0vO_sqFJWd; Tue, 23 Jan 2018 09:09:36 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C79CD72; Tue, 23 Jan 2018 09:09:34 +0200 (EET)
Date: Tue, 23 Jan 2018 09:09:34 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Jacob Hoffman-Andrews <jsha@eff.org>
Cc: "acme@ietf.org" <acme@ietf.org>
Message-ID: <20180123070934.GA6737@LK-Perkele-VII>
References: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/M_NyDXHayY_Y6hDYq7RMx6dI8zA>
Subject: Re: [Acme] Assisted-DNS challenge type
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, 23 Jan 2018 07:09:43 -0000

On Mon, Jan 22, 2018 at 05:09:53PM -0800, Jacob Hoffman-Andrews wrote:
> 
> To fix that, the CA could assist the user by providing narrowly-scoped
> DNS hosting: It would serve only TXT records used in validating DNS
> challenges. The CA instruct subscribers to delegate the _acme-challenge
> subdomain to a subdomain of the CA's hosted DNS domain. For instance, if
> a subscriber has account number 1234, the CA would say: Please deploy a
> CNAME record like so:
> 
> _acme-challenge.example.com. CNAME 1234.challenges.ca.example.net.
> 
> The assisted-dns-01 challenge would then be validated like dns-01,
> except: As the first step in validation, the CA would deploy the
> expected TXT value at 1234.challenges.ca.example.net. Then the CA would
> continue to look up "TXT _acme-challenge.example.com." In a way,
> fetching final TXT record would be a formality: the CA could in theory
> stop once it saw the CNAME pointed at the right location, though most
> likely abiding by the terms of the BRs would require following the
> formal lookup steps.
> 
> This challenge has the big advantage that subscribers only need to do a
> one-time CNAME setup, and renewals can be reliably automated without
> requiring that renewing systems have permission to update DNS. In
> effect, the CNAME record would act like a long-term delegation
> permitting the CA to issue continuously for the base domain.

I came up with very similar method when trying to figure out how the
Amazon Certificate Manager DNS challenge works. It has similar
"standing authentication" property, and yet needs to comply with the
BRs.



-Ilari