Re: [Acme] dns-01 challenge limitations

Simon Ser <contact@emersion.fr> Fri, 11 September 2020 13:25 UTC

Return-Path: <contact@emersion.fr>
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 D1CC43A0770 for <acme@ietfa.amsl.com>; Fri, 11 Sep 2020 06:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=emersion.fr
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 NE69avofZXR0 for <acme@ietfa.amsl.com>; Fri, 11 Sep 2020 06:25:07 -0700 (PDT)
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4D13A041C for <acme@ietf.org>; Fri, 11 Sep 2020 06:25:06 -0700 (PDT)
Date: Fri, 11 Sep 2020 13:25:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail2; t=1599830704; bh=u10UFgGT06sJjPWvKDhK1yr5UH1QrmM+WWObhIKyLn8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=ejUV3cwlVk+RjtxKe91HOJ5LIYhB+gscfqXOziPcmxgZ4EV5XYBz9U3mA2+2nnxPi hRgugilm5lYGuTJpqqYeyCSOBY0lmF0TmLQEnyj3SEgOXZX/4+94sRJ7SgkzRIvOy6 dbqwfLfcAbFhu7TfENPYFLjc4qUcGWpmvhE//nuc11bXL7fejDrQjCntz9X0rZ75qU L0A5JNowI7jB81+lo21ARadIuPeCOjZ4GoCRoxvzgq6gAyDXQN69yWc8LUO4xJc0oP UTd5KLR04Jj4Zgi19QGG+zNgcIAI1qUNDBf0nuoDaBCrflYRucCrqx1K2HKVwS9WGY rgDrLHuvwnH+g==
To: Felipe Gasper <felipe@felipegasper.com>
From: Simon Ser <contact@emersion.fr>
Cc: "acme@ietf.org" <acme@ietf.org>, "Matthew.Holt@gmail.com" <Matthew.Holt@gmail.com>
Reply-To: Simon Ser <contact@emersion.fr>
Message-ID: <uTb0VcadGuNvEnDsg15ER29Kge26GImPfZ-JqS6iFkGXEn4DOFmq8V-hAb32lZNpv6r5rtfrZn6pihdDQkyts_I6BK4tni8CNMYC2RgSorU=@emersion.fr>
In-Reply-To: <394568F0-00BD-4789-8CF4-C1A00A078B6E@felipegasper.com>
References: <uu-OR5wP1b7svN1Rxems1U8_axHG7M8M9_kYqTBVyhQFxqrddppvhasyxKtLQ-4AZkrbBWhJ_9V-Xs8mQBK5E4smP4_1vANgZazIwicsbq0=@emersion.fr> <394568F0-00BD-4789-8CF4-C1A00A078B6E@felipegasper.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/nwJ4qoelQt-LDIXnSF_2QqACPCc>
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: Fri, 11 Sep 2020 13:25:09 -0000

Hi,

On Friday, September 11, 2020 3:17 PM, Felipe Gasper <felipe@felipegasper.com> wrote:

> > On Sep 11, 2020, at 9:08 AM, Simon Ser contact@emersion.fr wrote:
> > For instance, it would be possible to require users to add a short public key
> > in a DNS TXT record, then ask the ACME client to sign challenges with that key.
> > Something like this would significantly ease the development of ACME clients.
>
> This would seem to introduce a new vector--key compromise--for being
> able to impersonate the domain, wouldn’t it?
>
> Such an authz method would be proving not access to the domain
> itself, but access to the key, and would be vulnerable to local
> misconfigurations. It seems thus not dissimilar to the erstwhile
> problem with tls-sni-01/02.

Right now ACME clients need vendor-specific authorizations, like API
tokens. If the DNS registry operator's token is leaked, much worse
things can happen than just being able to issue wildcard certificates
(since the token provides write access to DNS records).

Thanks,

Simon