[Acme] Proposal for http challenge: Lookup SRV records before A/AAAA records

Michael Wyraz <michael@wyraz.de> Tue, 09 February 2016 21:37 UTC

Return-Path: <michael@wyraz.de>
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 44D0B1B2A5F for <acme@ietfa.amsl.com>; Tue, 9 Feb 2016 13:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no
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 8QueqcCY84oS for <acme@ietfa.amsl.com>; Tue, 9 Feb 2016 13:37:06 -0800 (PST)
Received: from mail.wyraz.de (web.wyraz.de [37.120.164.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C4C1B2A5D for <acme@ietf.org>; Tue, 9 Feb 2016 13:37:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.wyraz.de (Postfix) with ESMTP id 8D148A3148 for <acme@ietf.org>; Tue, 9 Feb 2016 22:37:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at web.wyraz.de
Received: from mail.wyraz.de ([127.0.0.1]) by localhost (web.wyraz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg74L9WX9dhx for <acme@ietf.org>; Tue, 9 Feb 2016 22:37:03 +0100 (CET)
Received: from [192.168.1.200] (p578521F0.dip0.t-ipconnect.de [87.133.33.240]) (Authenticated sender: michael@wyraz.de) by mail.wyraz.de (Postfix) with ESMTPSA id D8E54A3147 for <acme@ietf.org>; Tue, 9 Feb 2016 22:37:02 +0100 (CET)
To: acme@ietf.org
From: Michael Wyraz <michael@wyraz.de>
X-Enigmail-Draft-Status: N1110
Message-ID: <56BA5BFF.2040207@wyraz.de>
Date: Tue, 09 Feb 2016 22:37:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="sQ76sGnvI1OpjUjfhsr8RRsgC996xouOe"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/ajWjn9UXHwZp8mSwmarYrPvnReY>
Subject: [Acme] Proposal for http challenge: Lookup SRV records before A/AAAA records
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: Tue, 09 Feb 2016 21:37:07 -0000

Hi,

as discussed before, acme/http-01 is difficult to implement if the
domain being validated does not resolve to the IP address of the machine
where the client runs on.

Common cases are:
- multiple physical servers behind a tcp balancer (A-Record resolves to
the load balancer, not to the server where the acme client runs on).
- geo based dns resolution (A-Record resolves to the "nearest" server
which is not necessarily to the server where the acme client runs on)
- A-Record resolves to a device that is not able to run the acme client
(hardware firewall, router, load balancer)

I've created a proposal for using SRV (with fallback to A/AAAA) to solve
these issues: https://github.com/ietf-wg-acme/acme/pull/83

As you can see, the change only affects a small part of the server side
of the protocol and should have minimal impact to implementations.

Let me know what you think about it.

Kind regards,
Michael.