Re: [Acme] Assisted-DNS challenge type

"Matthew D. Hardeman" <mhardeman@ipifony.com> Wed, 24 January 2018 23:47 UTC

Return-Path: <mhardeman@ipifony.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 B465812D849 for <acme@ietfa.amsl.com>; Wed, 24 Jan 2018 15:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 9jpbLzfnmTin for <acme@ietfa.amsl.com>; Wed, 24 Jan 2018 15:47:46 -0800 (PST)
Received: from mail.ipifony.com (mail.ipifony.com [199.71.210.39]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317EC12D838 for <acme@ietf.org>; Wed, 24 Jan 2018 15:47:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.ipifony.com (Postfix) with ESMTP id A9DD0B4091A; Wed, 24 Jan 2018 17:47:45 -0600 (CST)
X-Virus-Scanned: amavisd-new at ipifony.com
Received: from mail.ipifony.com ([127.0.0.1]) by localhost (mail.ipifony.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE3fygqT76NQ; Wed, 24 Jan 2018 17:47:44 -0600 (CST)
Received: from [10.47.52.51] (68-117-162-146.dhcp.unas.al.charter.com [68.117.162.146]) by mail.ipifony.com (Postfix) with ESMTPSA id C3650B40447; Wed, 24 Jan 2018 17:47:44 -0600 (CST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: "Matthew D. Hardeman" <mhardeman@ipifony.com>
In-Reply-To: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org>
Date: Wed, 24 Jan 2018 17:47:43 -0600
Cc: "acme@ietf.org" <acme@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <44CCE26D-2C11-4AB8-8603-E8DAC4D67757@ipifony.com>
References: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org>
To: Jacob Hoffman-Andrews <jsha@eff.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/9g6ETYD4LLAE_gCeNO9l_i7yJFk>
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: Wed, 24 Jan 2018 23:47:48 -0000


> On Jan 22, 2018, at 7:09 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
> 
> 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.
> 

In the scheme you propose here, the optics of the situation may be a concern.  The fact that the lookup is a formality because the CA directly altered the the records opens the door for objections and ballots to revise the “work around”.

Why not operate the special limited DNS infrastructure in a way that even a non-CA party could theoretically own/manage that infrastructure in a manner that doesn’t require the CA itself to trust the third party?

Have the target CNAME zones assigned at random and bound to an account key or similar, standardize an API for requests for new CNAME target labels to be assigned for use and for updates to be executed by the ACME client directly.  In other words, don’t have the CA modify the target CNAME label’s TXT records — let the ACME client do it.

Provide an API which lets any ACME client user apply for a new random target CNAME label, perhaps in an account-id hierarchy, bound to a cryptographic key for updates/adds of TXT records in that zone or on that label and then you can run it or any other party trusted by the ACME client who makes the delegation to the remote label can be chosen.

The fetching by the CA validation logic in this case is no longer a formality nor is it any kind of stacked-deck farce and it is no longer strictly necessary that the dynamic limited DNS provider even be the CA.  (Albeit the dynamic limited DNS provider DOES need to be a trustworthy party AND a party trusted by the subscriber.)

Technologically, the merits of my proposed change are limited.  In terms of the optics, this opens the door to real separation from the CA as well as has the client demonstrating something more akin to material control of the target dynamic zone, reducing arguments that the mechanism is an end-run of any kind.