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

Ryan Pendleton <me@ryanp.me> Fri, 04 December 2015 09:52 UTC

Return-Path: <me@ryanp.me>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC271ACEF8 for <acme@ietfa.amsl.com>; Fri, 4 Dec 2015 01:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
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 HFjwWyxNEecN for <acme@ietfa.amsl.com>; Fri, 4 Dec 2015 01:52:57 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C851ACEEA for <acme@ietf.org>; Fri, 4 Dec 2015 01:52:57 -0800 (PST)
Received: by pacwq6 with SMTP id wq6so7430751pac.1 for <acme@ietf.org>; Fri, 04 Dec 2015 01:52:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ryanp.me; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=NUAJa9dN7Uthf2fXh8ki+qujT5JcX46yO8izxwXGcLk=; b=ZIRmbfY3yZuEkWXZnsReFVYVhQOfPbSwiXeYWbb2vsfNrChFZsWJ1NTaKB1SFNsgkN 3lUvg2e8YYix2ALpdlMKKkqjpJsWAjywetqE72DS2HW7ReFPtgPXekezQq4lwyOAgeQ7 eAQAUy8st8/iAM006FHqK7LIXqS+AqItqGe/s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=NUAJa9dN7Uthf2fXh8ki+qujT5JcX46yO8izxwXGcLk=; b=ck44T0jSkeC5dl65XmXdPGfPOwzRK4YGqReFPVsIeu672Dzd48tuRuJl6COHHiTw18 IAPgyo8VsCZtSM4PwCQT5D2H6ITLKFRpHomvbewkWUoWs/vm7p06LU2zQmpxW1o05kCE UNhiX7+toF/uehS+wFOyLfXj7C6Q0aCvXHZ4MlzswLqX4Vdotr6goHXV7g2lRfSweugD Hvo1AudsaPVh8pLlQ4q4OYsIp1CCmkQ4nLEobUXaL1MAMWNJk6E3SNeKwUOqAojGDL57 04B99p3dmLQODoFOz5Sr3p8XbUk3KYP+qrWTyEZjxFyTvhhT5Uf+O2EQCCBEdBfLguo5 HseQ==
X-Gm-Message-State: ALoCoQlrWizKOvrn8FKUgIsn00EEF/kjRKvM2/97gHV2UaBWG8Zl2HOJV5KknDrm6coWRm/zLcGs
X-Received: by 10.66.216.200 with SMTP id os8mr20237300pac.143.1449222777189; Fri, 04 Dec 2015 01:52:57 -0800 (PST)
Received: from ryanp.me ([45.56.29.18]) by smtp.gmail.com with ESMTPSA id rz10sm15964800pac.29.2015.12.04.01.52.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2015 01:52:56 -0800 (PST)
Date: Fri, 04 Dec 2015 02:52:54 -0700
From: Ryan Pendleton <me@ryanp.me>
To: Peter Eckersley <pde@eff.org>
Message-ID: <20151204095254.GA29937@ryanp.me>
References: <565C84A1.9040102@wielicki.name> <20151204084601.GQ18430@eff.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20151204084601.GQ18430@eff.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/dMQKdbdQ4WxtWjSd9L4atZmbgBY>
Cc: Jonas Wielicki <jonas@wielicki.name>, acme@ietf.org
Subject: Re: [Acme] Support for domains with redundant but not immediately synchronized servers
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Dec 2015 09:52:59 -0000

Personally, I think that's a more appropriate approach.

Even if a protocol change was made that allowed an ACME client to pin
the challenge to a certain IP address, the requested IP may not always
be returned by the authoritative DNS server. Any type of latency, geo or
weighted routing algorithm could potentially get in the way.

On Fri, Dec 04, 2015 at 12:46:01AM -0800, Peter Eckersley wrote:
> 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.
> 
> Are there any cases where that is sufficiently unworkable to warrant a
> protocol change?
> 
> On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > Hi list,
> > 
> > I have asked this in the IRC and was pointed to this mailing list. I
> > tried to get a certificate for klausurschokola.de via Let’s Encrypt
> > during the currently running limited beta (we have the domain
> > whitelisted). The name has the following address records:
> > 
> > 1800 	IN 	A	176.9.101.187
> > 1800 	IN 	A 	217.115.12.71
> > 
> > (in addition, there is one AAAA record for each of the machines
> > addressed by the A records)
> > 
> > As you can see, two different machines are addressed. Those are
> > physically separated machines with different main administrators.
> > Both are pulling their web content from the same source, but it is not
> > supposed to be dynamic, so there is no "fast" (order of seconds) way
> > to mirror the content.
> > 
> > Our wish would be to be able to use different private keys and
> > certificates for both hosts, and renew these independently from the
> > other host. We thought that this would be possible using Let’s Encrypt.
> > 
> > The problem is that currently, the Let’s Encrypt server sometimes
> > chooses the wrong of the two IPs to ask for the file in
> > /.well-known/acme-challenge. Ideally, it would use the IP of the
> > requester (of course only after it has verified that the IP is in the
> > DNS) or allow the requester to specify a preferred IP.
> > 
> > For example, on 176.9.101.187:
> > 
> > # letsencrypt certonly -c ~/schoko.ini -d klausurschokola.de -d
> > www.klausurschokola.de
> > 
> > [… curses …]
> > 
> > Failed authorization procedure. klausurschokola.de (http-01):
> > unauthorized :: The client lacks sufficient authorization :: Invalid
> > response from
> > http://klausurschokola.de/.well-known/acme-challenge/c5HJrtp8t8JhfNgTXVC
> > 8N7OsCrguAWGw-JTIJxCFeIQ
> > [217.115.12.71]: 404
> > 
> > 
> > Is such a thing planned? Are there security reasons against doing
> > this? Are there security reasons against doing this on a DNSSEC signed
> > domain (which klausurschokola.de is)?
> > 
> > best regards,
> > Jonas
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> > 
> > iQIcBAEBCgAGBQJWXIShAAoJEMBiAyWXYliKJ1wP/iGVeGRxnAkrAstfjeGLvLeC
> > TXnF76X/8xC3s4dd/UR0DE2n9Pdn0FYCK+6jRTn+Xpa0MvrA2ME20AZMh070Ghy0
> > JRbdTWqjQTHzvjXYQHjSkW24pyZNgdfnmwd0HiAhn1mANv3dhVTnHR4hibZww+Su
> > ty3XzsyZYjrfQ3K5/bTb/jz+QZUoZ/fJJuNlyMsVInF3rzagj34WWR4sYbAIwKEF
> > CTvBFxINY04pUeemYlywPYrUOmcJTOK/wVi1ya2BgLgTqNJP5FJOX5jCHHr8m5ej
> > A7G/nGWFSybOG1GkjMOdST3uMeL7HlpqhUnuNzsiC3ZAfmgVwceLsG3bTCAxcrgB
> > 7XiSs3MrURuEk17w2QB0Oyt487DrmftzFo3vzvCrrl42au9JV69Y14/0W3z5piYM
> > DIGpd/KNSL2m6xvzoJHoi+o5lTl9GiP6KQKlJiIUtn2cz8Ro6CiwXkhD0FmG8sP7
> > 4wqg+vnpcTdhrzsWuAPrpGej+GT1LlWOLERnyPOfVhQ8EUPanwgUbGo1uTfHB2mj
> > T2CdCCZhcmJFurvz+7FVI1WaVgGR/rdZbu4ueC+0YNZEOICXE0pIJEw8rKWJbqe3
> > lKchgpR6jR3TKHHwNFDIZj049TBiEGxMXsdEaGlLOHdnr4ZlIDgfycumhYVTNJUi
> > IDHRifjFUchCynluOhZi
> > =3akD
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 
> -- 
> Peter Eckersley                            pde@eff.org
> Chief Computer Scientist          Tel  +1 415 436 9333 x131
> Electronic Frontier Foundation    Fax  +1 415 436 9993
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme