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

Jacob Hoffman-Andrews <jsha@eff.org> Thu, 03 December 2015 23:26 UTC

Return-Path: <jsha@eff.org>
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 0336F1A1A04 for <acme@ietfa.amsl.com>; Thu, 3 Dec 2015 15:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NBx8Ymmd0hif for <acme@ietfa.amsl.com>; Thu, 3 Dec 2015 15:26:54 -0800 (PST)
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 2D22F1A066B for <acme@ietf.org>; Thu, 3 Dec 2015 15:26:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=yulyIn8dwst70Dp8TWTZFjKWDqzBrlgWTkufbCf7lk0=; b=xJo77Rxbc3+QybHd8iSxnHvIhAjd9c0w+GDZwTMv8b5J6AhCa4PHQjYAZnY6oFO4dSC5C1dauhy6Hx+dhHy+FlFXokBinqdvNFcsuLsv/j8fpvy4wNq/IyZ54vTlR85mskIcYL22Hr7rSN1l4DlAYAxr6i9RgMzhZwV2pO4SbnE=;
Received: ; Thu, 03 Dec 2015 15:26:53 -0800
To: Jonas Wielicki <jonas@wielicki.name>, acme@ietf.org
References: <565C84A1.9040102@wielicki.name>
From: Jacob Hoffman-Andrews <jsha@eff.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <5660CFB2.4070508@eff.org>
Date: Thu, 3 Dec 2015 15:26:42 -0800
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: <565C84A1.9040102@wielicki.name>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fhgW52Cg1Oddw0aU9lWqCHuGLSVWbtAC4"
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/280AHAFUlSZEcCFZnBENgQyb3vk>
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 23:26:57 -0000

I think there are a few possible approaches to domain validation for
hostnames that resolve to multiple IP addresses:

1) It is sufficient to deploy a challenge response on any IP address.
2) The challenge response must be deployed on all IP addresses.
3) The server tries one deterministic IP address and succeeds or fails
based on whether the challenge is deployed there.

Let's Encrypt currently does (3), but it's probably the worst of both
worlds and we should fix it.

Arguably (2) is the most secure, since a single-machine compromise isn't
sufficient to issue a certificate.

And (1) is the easiest and most user-friendly. I think it's also similar
to existing practice in the wild.

Jonas, security-wise your proposal is equivalent to (1). Rather than
adding a preferred IP address to the spec, why not specif that ACME
servers SHOULD implement (1)? Alternately we could state in the spec
that the choice of IP is a policy choice of the CA, and lay out the two
most reasonable options (1 and 2).

On 11/30/2015 09:17 AM, Jonas Wielicki wrote:
> 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
> > _______________________________________________ > Acme mailing list >
Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme