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

Jonas Wielicki <jonas@wielicki.name> Thu, 03 December 2015 20:57 UTC

Return-Path: <jonas@wielicki.name>
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 32C9D1AC40E for <acme@ietfa.amsl.com>; Thu, 3 Dec 2015 12:57:06 -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 h31LUJfEXgjz for <acme@ietfa.amsl.com>; Thu, 3 Dec 2015 12:57:03 -0800 (PST)
Received: from sol.sotecware.net (sol.sotecware.net [78.47.24.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960E21AC40D for <acme@ietf.org>; Thu, 3 Dec 2015 12:57:02 -0800 (PST)
Received: from altair.sotecware.net (x4d05a411.dyn.telefonica.de [77.5.164.17]) by sol.sotecware.net (Postfix) with ESMTPSA id 353FD2006D2 for <acme@ietf.org>; Thu, 3 Dec 2015 20:57:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1449176220; bh=xKZybby2PkqvXLhh+9yS+nvJ5WkdmKL+4Hrlf0RCEb0=; h=Subject:To:References:From:Date:In-Reply-To; b=WIf2qlXtZ+SwvDCSJxlyKpdlIY36n0tdxOsEBLgnOWs/VV7J7pCKeBDFCnoDd3c7u I1Ku7xVa4itaZ1JLa//TFBnHPXLo19cbvJ6Hs090LQxs1t+AjGBO3bm9pMaQydYpqG kvmmM576EQ6aBVM1FiR1w0n/HNm8x0Lugc1Yw9unTrPuC2/elsjIrjIifh0vi/ffdu pCNQi2sMI9z09a+xmBwCUdypFlN1V5AcPEZvLNMGt4zGJ3T4bzeFOfd+AE6w88VJ1M EWvukCA0StxCMDH7SqiHetN9jPwotP+KKYqnC19AUloRhbUuRNQ5WzTGksRmqQBM35 +y+T9hgzKDjYw==
To: acme@ietf.org
References: <565C84A1.9040102@wielicki.name> <20151201013638.GA29577@andover>
From: Jonas Wielicki <jonas@wielicki.name>
Message-ID: <5660AC99.3020506@wielicki.name>
Date: Thu, 03 Dec 2015 21:56:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151201013638.GA29577@andover>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/v37h5aORZRqi-T5USFqTmOUr_wU>
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: Thu, 03 Dec 2015 20:57:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 01.12.2015 02:36, Hugo Landau wrote:
>> 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)?
> 
> Personally, I wouldn't think it unreasonable to allow an ACME
> client to request that a specific IP be used for the purposes of a
> challenge. The server would then verify that that IP is one of the
> candidate IPs, rather than selecting one at random. I don't see
> that this causes any loss of security, so it seems like a sensible
> inclusion.

That is great to hear! What is the preferred course of action now?
Should I open an issue on the protocol draft repository? (Which I
assume is at [1])

best regards,
Jonas

   [1]: https://github.com/letsencrypt/acme-spec
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWYKyHAAoJEMBiAyWXYliKEfAP/A4pTkT/4exKxW3nvv1VTUex
zunTI0G9lGnGDZ6vtJwTp28LiI3xqyMW1N32d525zSsaxphQljBstMQZPuW5SDIe
MKNceHyocXyBY+39wFWQMeVC4q4GsFBKSVLCyypvnW1EBjDGRwmQ6+KsF73fjQpF
zJBemiQsEx2wvj3XzuKzmI1r+7VauPCr1vk+R8238Kyr2GXYiQsDT0sf2dLsjTmt
Hg71wUH8gjcSrIlahOKPmbI0KUeqrToF3gOgY18fSFIzDkY7eMxtudHMdooz66rX
odAoqQFB2+Zx+WWo+2GJUNJ9V0JJGxRdanuhsjneLKdD1JXD3IKf9iCeT7ddBcVE
zsIp9i2XP0BGdVF6ZTvFB0j2iPxzJbEtJRAjYrqIRpnpy+sEBRvh9ShMOoPHHd6B
O8WljnLP6gbI8yf7j2iODtEkuWGCntM4jweash9wDTTq78Z8v5bjmSb4rQCCsBSM
0EwHATLTPP0oPFnFOaz+jYKexwKxJqkT9AwAGxY2SChFJbj/NV6k0c+Ng7FzJXy9
thcQ6AUJlgrvCi4fx9jukfZr0RiO2u26q0O+KGKUf9lMrWLwda/AKSnpI7v2OBNZ
dMaojNjdaumHovw/3BYeNlm+00QHF5Zl0M2R7tOpknvfazXeEtzxEeEZKQ8jdwbM
ZC2tMCXy4RulY1HARJXM
=rTxj
-----END PGP SIGNATURE-----