IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Fri, 04 December 2015 12:49 UTC

Return-Path: <ynir.ietf@gmail.com>
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 2239A1B3108 for <acme@ietfa.amsl.com>; Fri, 4 Dec 2015 04:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 2TP3Z_zXtYVn for <acme@ietfa.amsl.com>; Fri, 4 Dec 2015 04:49:00 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 9B99F1B3105 for <acme@ietf.org>; Fri, 4 Dec 2015 04:48:59 -0800 (PST)
Received: by wmec201 with SMTP id c201so63792304wme.1 for <acme@ietf.org>; Fri, 04 Dec 2015 04:48:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DXDE6ePju9908TE1iw5TX0b/WO7lrZdTWWIrfUBfPFk=; b=qeywrmyKH6416XiCjAH7lUtxQvm9lnt5/q7UsrU7rT54jBaAeT2DAe10lnnjrVQT8T iwaZayx2rUdhVJK9hvD1uIsmztZC5lNAmzxu669mnIveDfOyHygKgvKJCgnecmgJLiWp kJU3sDO55E/N59yyO0UmJzVXGZEqWSTImj/rr0rAlZcX4xVCJxjoifBqZWtkFzniDhTM HcsuTaOHEHqNLZiVXWC/D6p3KCCfPPZFqbb0DDGqCQNpy+irqL1ZmmYx3dQ6vXdyZC1Q Zk2yjHIOWAIWWN1CzcLkRs7Q6MKrsQsaIGujhfNjMKl/frWLHBNnqJifIrUqRs+C3bJd ka8w==
X-Received: by 10.28.182.11 with SMTP id g11mr5172840wmf.42.1449233338247; Fri, 04 Dec 2015 04:48:58 -0800 (PST)
Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id u134sm3410704wmd.0.2015.12.04.04.48.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 04:48:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20151204095254.GA29937@ryanp.me>
Date: Fri, 04 Dec 2015 14:48:54 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <127ED7F0-0D59-4472-94ED-FE5FA477ADEF@gmail.com>
References: <565C84A1.9040102@wielicki.name> <20151204084601.GQ18430@eff.org> <20151204095254.GA29937@ryanp.me>
To: Ryan Pendleton <me@ryanp.me>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/-GGDKYRYxQ1usJJ8fMLnAkVJOZU>
Cc: Jonas Wielicki <jonas@wielicki.name>, Peter Eckersley <pde@eff.org>, 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 12:49:01 -0000

+1

> On 4 Dec 2015, at 11:52 AM, Ryan Pendleton <me@ryanp.me> wrote:
> 
> 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?
>>

v2.23.0 | Report a Bug | By Email