Re: [Acme] dns-01 challenge limitations

Kas <kas@lightc.com> Sun, 13 September 2020 09:42 UTC

Return-Path: <kas@lightc.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 6FDD23A0B8A for <acme@ietfa.amsl.com>; Sun, 13 Sep 2020 02:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lightc.com
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 DHv3Ka1KHcws for <acme@ietfa.amsl.com>; Sun, 13 Sep 2020 02:42:33 -0700 (PDT)
Received: from mail.lightc.com (mail.lightc.com [51.38.25.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388C83A0ABC for <acme@ietf.org>; Sun, 13 Sep 2020 02:42:33 -0700 (PDT)
dkim-signature: v=1; a=rsa-sha256; d=lightc.com; s=rsakey; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=NdwL4siEoJoykHIUJ0ihRHwHjWUkE3uoCx1v6U26Gp0=; b=Vm3pXtcH2/wsE8I/TKhfTIRjgc3c3j9EWSZ9J80d4+5uGKphlEmsiGgyjjAWO+dgc5oR0iWiw/0IUBTuM6fAbmXFfCs/qyKDB9y0G3UKrIdxV61P5G4sc5e82tRslNAWGXjufiN7PnoYCwlWUR7tLp/FyZpyZxG+ONVp4GjVig6YD7n6Ct4b3odfMCqkTx3SZ6hy1UmSYphsDEwIHqrl8oMDDhVVLQCRDYzULu+DNHSd97MOW9ChKX5TUP BveGJm9sjjBoOgkwccMGSNyGAxKD2A65Ii8w2EGFeHKlQWBObgqZ8N1OwB/YNNqaWGh+yynoQsuhyBAaSLmJpOtdjJIQ==
Received: from [192.168.1.50] (Unknown [46.149.55.2]) by mail.lightc.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Sun, 13 Sep 2020 12:42:26 +0300
To: Simon Ser <contact@emersion.fr>, "acme@ietf.org" <acme@ietf.org>
References: <uu-OR5wP1b7svN1Rxems1U8_axHG7M8M9_kYqTBVyhQFxqrddppvhasyxKtLQ-4AZkrbBWhJ_9V-Xs8mQBK5E4smP4_1vANgZazIwicsbq0=@emersion.fr> <CACHSkNq9D5tYpaYm+_336+7WkJxuRw6_zPgEUtfMqaqbDr+zww@mail.gmail.com> <RIUPM_G4wCA2zxzlMxWZp78us6ljwnWaD3n4L4kRuxYeZkEudsnLnD4b6TllCoUoTlJy0FzcJIKQ5HHuNkYPWbrkmy6yGyDQPuYubQqsrQ8=@emersion.fr> <CACHSkNrc6Gnqwfq2OzgEqvCCrhKb3SLO9YJOcDRTPV3s27OZJQ@mail.gmail.com> <CAErg=HFTsQmzacEP2K542nFWrJhcGVWE+Q2GndMnAvpSMDBCeg@mail.gmail.com> <mWZh6EINiNadii7akjphaUVgUqHjKRG_rbv6M91CxWsaCuPq7wIGJi8TfgsJWu6tFrSpnFViVNvL4XNzBEPKcc4iB10qy9Bt5lauORap1pg=@emersion.fr>
From: Kas <kas@lightc.com>
Message-ID: <44847933-7f96-67bb-6fbe-234b9410d307@lightc.com>
Date: Sun, 13 Sep 2020 12:42:02 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <mWZh6EINiNadii7akjphaUVgUqHjKRG_rbv6M91CxWsaCuPq7wIGJi8TfgsJWu6tFrSpnFViVNvL4XNzBEPKcc4iB10qy9Bt5lauORap1pg=@emersion.fr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/SHbIj6WrMF_w8_rHrGVBm_SPe6I>
Subject: Re: [Acme] dns-01 challenge limitations
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 13 Sep 2020 09:42:35 -0000

On 9/13/2020 12:13 PM, Simon Ser wrote:
> Ultimately, ACME clients need a way to update DNS records to solve the dns-01
> challenge. Ignoring and pushing the problem down to the DNS operators does not
> fix the root cause.
I can't agree more, so what about going after dns-02 challenge instead 
of trying to fix this ?

(And this is up for discussion and as food for thought.)
Lets say dns-02 challenge will be little different where the DNS record 
will hold a public key for specific(or per) domain/subdomain and ACME 
client will pass the server challenge by using the correspondent private 
key for that public key to pass the challenge from the server, where 
server will verify against the DNS published public key, means no DNS 
access from client side at the time of the challenge itself.

This might solve the need for DNS API or even accessing the DNS from the 
client altogether, this will solve and simplify the challenge while do 
not compromise the security of the challenge itself and will not 
compromise the DNS records for the DNS administrators piece in mind, on 
contrary it will give the ability to control DNS handling on the client 
side in more secure way, and yet if a client have the ability to change 
the public key then this will revert to something very similar to 
dns-01, so in that case ( when it can access and modify the DNS records) 
client can choose between dns-01 and dns-02, which i don't see need any 
discussing more that dns-01 itself.

Is such challenge viable and secure ? did i missed something obvious 
with such suggestion ?