Re: [Acme] Assisted-DNS challenge type

Thomas Lußnig <lussnig@suche.org> Tue, 23 January 2018 09:12 UTC

Return-Path: <lussnig@suche.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 0EDA1124BAC for <acme@ietfa.amsl.com>; Tue, 23 Jan 2018 01:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 i4ZJQXrUgMZL for <acme@ietfa.amsl.com>; Tue, 23 Jan 2018 01:12:43 -0800 (PST)
Received: from relay-mx.smcc.de (relay-mx.smcc.de [194.50.33.90]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440A1124205 for <acme@ietf.org>; Tue, 23 Jan 2018 01:12:42 -0800 (PST)
Received: by mx-32.smcc.de (Postfix, from userid 65534) id 20B7B56393; Tue, 23 Jan 2018 10:12:41 +0100 (CET)
X-Spam-SCL: 1
Received: from localhost (localhost [127.0.0.1]) by mx-32.smcc.de (Postfix) with ESMTP id DD98B562B3; Tue, 23 Jan 2018 10:12:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx-30.smcc.net
Received: from relay-mx.smcc.de ([127.0.0.1]) by localhost (relay-mx-02.smcc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fv1t_3zsYq3; Tue, 23 Jan 2018 10:12:39 +0100 (CET)
Received: from mail.smcc.net (localhost [127.0.0.1]) by mx-32.smcc.de (Postfix) with ESMTPA id BB9E85623E; Tue, 23 Jan 2018 10:12:39 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 23 Jan 2018 10:12:39 +0100
From: Thomas Lußnig <lussnig@suche.org>
To: Niklas Keller <me@kelunik.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, acme@ietf.org, Jacob Hoffman-Andrews <jsha@eff.org>
Reply-To: lussnig@suche.org
Mail-Reply-To: lussnig@suche.org
In-Reply-To: <CANUQDCie2BRuqpH0EvpefhVW2YgMiwEGGo8wwrWsDh6T71kxrQ@mail.gmail.com>
References: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org> <20180123070934.GA6737@LK-Perkele-VII> <CANUQDCie2BRuqpH0EvpefhVW2YgMiwEGGo8wwrWsDh6T71kxrQ@mail.gmail.com>
Message-ID: <ed29b136a6f97cb67eb54cb9097f3a6f@suche.org>
X-Sender: lussnig@suche.org
User-Agent: Roundcube Webmail/1.3.4
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/2_mSWBJ9lzt30sIlCsTRUSh_FGU>
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 09:12:59 -0000

Hi,

instead of an FIXED cname that does not ensure that the requestor 
possess access to the dns.
I would prefer to use an static TXT record whith the Account Key hashed. 
This would prove that
only an person possesing an specified private key is allowed to request.
Or to use TLSA record to verify that the requested zertificate would be 
valid for dane.
This would weaken the DNS-SEC Requirement for DANE but would not 
introduce an weakness compared
to the suggested solution.

Gruß Thomas

Am 2018-01-23 09:09, schrieb Niklas Keller:
> 2018-01-23 8:09 GMT+01:00 Ilari Liusvaara <ilariliusvaara@welho.com>:
> 
>> 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 [1]. CNAME
>> 1234.challenges.ca.example.net [2].
>>> 
>>> 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 [2]. Then the
>> CA would
>>> continue to look up "TXT _acme-challenge.example.com [1]." 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.
> 
> This seems very much like a circumvention of the BRs. Either this
> circumvention should be forbidden, because it effectively doesn't
> re-prove ownership, or the BRs can be changed to allow permanent
> authorization for accounts, then we don't need the CA to host anything
> like that.
> 
> We could then allow e.g. an account key thumbprint to authorize a
> specific account key to request certificates. Using the account key
> would allow that key to request those certificates from any ACME
> supporting CA, not just one. A binding could be introduced, but I
> guess CAA already solves that.
> 
> Regards, Niklas
> 
> Links:
> ------
> [1] http://acme-challenge.example.com
> [2] http://1234.challenges.ca.example.net
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme