Re: [Acme] Support for domains with redundant but not immediately synchronized servers

Jacob Hoffman-Andrews <jsha@eff.org> Thu, 09 June 2016 18:08 UTC

Return-Path: <jsha@eff.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 6D7F012D113 for <acme@ietfa.amsl.com>; Thu, 9 Jun 2016 11:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.428
X-Spam-Level:
X-Spam-Status: No, score=-8.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 Vnc35F5P2Lab for <acme@ietfa.amsl.com>; Thu, 9 Jun 2016 11:08:31 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834BD12D0BB for <acme@ietf.org>; Thu, 9 Jun 2016 11:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=tULJFPOWW25TKr+hS3Eeur6YcM7zElqzlod5Od8g9VY=; b=wJHcdfiyUaZYm8ycGITgU3JIrxjo4b/bMO/JrYumNWkTYnrQA+JY/lb+b2zvOwTgRWUPUiqHubK+NNdp7RHOXIbZbNkQE1B2gHbCiuHRjgxW12OXHKRi7nB9vxildBM4ni99Ccany1MUTQsGkWwH8ZrjJ/fyfiEmZcbusJn5tgg=;
Received: ; Thu, 09 Jun 2016 11:08:29 -0700
To: Jonas Wielicki <jonas@wielicki.name>, acme@ietf.org, Niklas Keller <me@kelunik.com>
References: <565C84A1.9040102@wielicki.name> <20151204084601.GQ18430@eff.org> <255B9BB34FB7D647A506DC292726F6E13BB473EFFB@WSMSG3153V.srv.dir.telstra.com> <56A0C558.2070202@wielicki.name>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <5759B09D.8060501@eff.org>
Date: Thu, 9 Jun 2016 11:08:29 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <56A0C558.2070202@wielicki.name>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/6RSxtvpkcQNPmKs9f45k_bi9QVo>
Subject: Re: [Acme] Support for domains with redundant but not immediately synchronized servers
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 09 Jun 2016 18:08:33 -0000

(Picking up an old thread)
> >> There's a fairly good solution available with the current
> >> protocol, which is to serve a (long lived) redirect from
> >> /.well-known/acme-challenge/ on all of the servers to a
> >> different URL that is always answered by the machine you run an
> >> ACME client on.
>
> > This redirect-based workaround feels far from ideal. It assumes 1
> > server does all the ACME bits, which discourages per-hardware
> > keys.
Having one server that can be relied on to initiate and validate
challenges does not discourage per-hardware certificate keys. The
individual boxes are always free to generate their own CSRs and request
issuance independently, once the challenge is completed. This assumes
that you want to trust the individual boxes with copies of the account
key, but the same is true in the model you're proposing.
> It requires more coordination between servers (1 is
> > different; others need its IP; need some extra mechanism to
> > distribute key+cert once issued).
In any fleet so large that you can't reliably push out a token to all
frontends within a week, there's already this degree of coordination.

A little more detail on why I'm so opposed to this change: It introduces
complexity into the protocol to solve something that is relatively
deployment specific. It also conflicts with established validation
practice in other CAs. I don't think any current CA allows you to
specify which IP address to visit for HTTP-based domain validation.

Additionally, this duplicates the intent of other parts of the spec.
Specifically, the DNS challenge is intended to offer a way to validate
hostnames that are served by large fleets of load-balanced machines. I
realize there are reasons why the DNS challenges is not convenient for
every deployment scenario, but I think we need a stronger argument than
that to justify adding the extra complexity here.