Subject: [Acme] Proposal: Allow http-01 to be delegated to a different host

From: Michael Wyraz <[email-masked]>
Date: Fri, 11 Dec 2015 21:50:51 +0100

Hi,

I'm new to this mailing list. Today I started a discussion on IRC about
the fact that ACME with http-01 won't work if the A record points to an
intranet IP address or is resolved dynamically dependent on geo
locations or similar. People in IRC recommended to do such discussions
in the acme mailing list ;-)

The idea to solve these issues is simple: why not using some special dns
record to resolve an URL that is responsible for ACME-challenges for a
certian domain? This is more flexible than building the URL based on
A-Record on a fixed scheme.

Example:
mydomain.com could have a TXT-Record "acme-http-01-url" that points to
some URL (e.g. http://acme.mydomain.com/acme-challenge). If this record
exists, this URL is used. Otherwise
http://mydomain.com/.well-known/acme-challenge is used as defined in
http-01.

Advantages:
- simple
- same security as in http-01
- decouples proof of domain ownership from physical device that the
A-record points to
- allows certificate issue for intranet services, embedded devices and
clustered services
- no dynamic dns updates required
- has only minimal impact in server implementations
- has no impact in client implementations

Please let me know what you think about this idea.

Kind regards,
Michael.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 11 Dec 2015 14:03:14 -0800

On 12/11/2015 12:50 PM, Michael Wyraz wrote:
> intranet IP address
In general, publicly trusted CAs are supposed to verify that a name is
available on the public Internet.

> or is resolved dynamically dependent on geo locations or similar.

This is a potential issue, and is similar to recently discussed issue
about choosing from multiple available IPs, but is a harder problem to
solve. If you push a challenge to just one geo region, a validation
attempt from a different geo region may not see any relevant IPs.

> A-Record on a fixed scheme.
If you're willing to accept a dependency on DNS, it makes sense to just
use the DNS challenge instead. I think that's probably the ideal
solution for services that have many frontends and do geo load balancing.

---

From: Thomas Lußnig <[email-masked]>
Date: Fri, 11 Dec 2015 23:17:06 +0100

Hi,

are there any information when DNS challenge will be available ?

Gruß Thomas

Am 11.12.2015 um 23:03 schrieb Jacob Hoffman-Andrews:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 11 Dec 2015 14:29:46 -0800

That's a Let's Encrypt rather than an ACME one, but to answer for Let's
Encrypt: soon! We're working on it. Followup to
https://community.letsencrypt.org/ if you have more questions?

Thanks,
Jacob

---

From: Michael Wyraz <[email-masked]>
Date: Sat, 12 Dec 2015 01:07:18 +0100

Jacob, thank you for your feedback.

The http-01 challenge/response already relies on static DNS (A-Record).
Nevertheless http is used for challenge. So using a (static) DNS record
other than A-record won't change anything to the http challenge itself.
The role of DNS is still the same (a directory).

The DNS challenge is completely different. It relies on dynamic DNS
updates during challenge which brings a lot of extra complexity.

The reason why DNS round robin or geo-based DNS is an issue with ACME is
that http challenge assumes that the A-record resolves to exactly one
static IP address and the device at this address is able to solve the
challenge (or at least to provide the solution of the challenge at the
well-known URI). IMO there are lot of situations where this assumption
is wrong. But there's a simple fix (decouple the challenge from
A-record) without the need for a completely different challenge type
(like DNS challenge). The big advantage of http challenge is that it is
simple to implement and generally available.

Regards,
Michael.

---

From: James Cloos <[email-masked]>
Date: Mon, 14 Dec 2015 14:23:53 -0500

>>>>> "JH" == Jacob Hoffman-Andrews <[email-masked]> writes:

JH> In general, publicly trusted CAs are supposed to verify that a name is
JH> available on the public Internet.

Why?  There is no value in doing that.

There's value in confirming that the name isn't someone else's, but
dlv certs issuers only need to confirm that the requester has control of
the name or a non-public-suffix parent of that name to provide the level
of security they claim to provide.

Creating certs for hostnames and service names which are only used
inernally and which are rooted in a zone name the requester controls
(so not things like local. or the like) is important, too.

Wireless can be sniffed (are you certain that "wifi security" is secure)
and most lans have untrustable commercial devices on them.)

Also, some machines inside the lan may ned to authenticate themselves to
machines outside; using the same cert for servier and client use is all
which some software supports.

ACME isn't only about https.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 14 Dec 2015 11:35:43 -0800

> On Dec 14, 2015, at 11:23 AM, James Cloos <[email-masked]> wrote:
> 

Internal hostnames will probably be better served by setting up a behind-the-firewall ACME CA and using that. As LE/ACME get more mindshare, hopefully we'll see some turnkey solutions for this if they don't exist already. Applying blanket assumptions that proof of ownership of a domain applies recursively to all subdomains seems like it is a only a matter of time until it turns into a security risk, or at least would require careful interaction with the existing validators.

--Noah

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Dec 2015 19:43:10 +0000

> ACME isn't only about https

>From our charter: "The initial focus of the ACME WG will be on domain name certificates (as used by web servers), but other uses of certificates can be considered as work progresses."

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Michael Tandy <[email-masked]>
Date: Mon, 14 Dec 2015 20:29:11 +0000

On 14 December 2015 at 19:35, Noah Kantrowitz <[email-masked]> wrote:

> Internal hostnames will probably be better served by setting up a
> behind-the-firewall ACME CA and using that.
>

I work for a company that runs its own internal CA and it's a hassle. I can
go into more detail about this if you like but suffice to say, we would be
much better served by a CA that was in most root certificate stores already.

With that said, I can understand why LE/Acme might prefer to limit
themselves to publicly accessible web servers initially.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 14 Dec 2015 18:34:44 -0500

Again, this discussion seems to assume that the validation mechanism is
validating the host that is to receive the cert as opposed to the holder of
the domain name.

If a site is using geo-location based services, things are going to get
really hairy. One possible response would be that this is a corner case
that isn't worth automating. The point of automation is to save effort, if
it is going to be more complex then don't do it.

A better approach would be to configure all the servers in the geolocation
cluster to route their certification requests through a LRA that has been
validated and can countersign the requests.

If we are doing that then the obvious way to link the LRA to the
authentication scheme is to put the cert or key fingerprint for the LRA
into a DNS record. For example use a CAA record.

But the more common case would be a site with two servers, both requiring a
certificate. Obviously, we would want each device to have a different
certificate. An LRA is overkill for that case. But you still need to be
able to make sure that the host that made a request can respond. Even if
firewall configuration means that outbound HTTP requests go on a different
IP address to inbound.