Subject: [Acme] Automated procedure for DNS challenge records?

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Mon, 3 Jul 2017 17:10:18 +0200

Hello,

is there any procedure proposed in the ACME documents to update the ACME 
resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs 
2136/2845)?

Best regards,

Renne

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Jul 2017 15:17:01 +0000

> is there any procedure proposed in the ACME documents to update the
> ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs
> 2136/2845)?

No, there is no DNS-update protocol specified.

But what ACME resource records are you thinking of?

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Jul 2017 11:30:00 -0400

There isn't anything in the current spec(s), and it doesn't really seem in
scope for this work.  That is, I don't think it's worthwhile to make a
one-off solution for updating the DNS with records for ACME, vs. improving
the state of DNS management in general.

That said, you can certainly integrate ACME tools with existing DNS APIs.
For example:

https://github.com/xenolf/lego/tree/master/providers/dns

On Mon, Jul 3, 2017 at 11:10 AM, Rene 'Renne' Bartsch, B.Sc. Informatics <
[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Mon, 3 Jul 2017 18:25:54 +0200

> But what ACME resource records are you thinking of?
For a fully automated validation process the ACME-client needs some kind 
of protocol/interface to add/update/remove the DNS challenge records on 
the primare DNS server.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Jul 2017 16:28:28 +0000

> For a fully automated validation process the ACME-client needs some kind of
> protocol/interface to add/update/remove the DNS challenge records on the
> primare DNS server.

This is out of scope for our WG, but since we are looking at rechartering, it could be brought within scope.

But I think programmatic maintenance of DNS records should probably be done within the DNS groups.

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Mon, 3 Jul 2017 18:46:29 +0200

> But I think programmatic maintenance of DNS records should probably be done within the DNS groups.

In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) 
there is already a protocol for clients to add/update/delete resource 
records on DNS servers. Most DNS server softwares support RFC 2136 out 
of the box. We just have to define a protocol to use (-> RFC 2136) in 
the ACME client.

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 4 Jul 2017 10:28:44 -0400

I agree with the others that have shared the opinion that this is outside
of the scope of ACME and this WG.

In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there
> is already a protocol for clients to add/update/delete resource records on
> DNS servers. Most DNS server softwares support RFC 2136 out of the box. We
> just have to define a protocol to use (-> RFC 2136) in the ACME client.

That's exactly right. At least one ACME client (Certbot) has been working
on support for RFC 2136 (https://github.com/certbot/certbot/pull/4701) in
addition to one-off provider specific DNS APIs.

If you need a generic way to update DNS dynamically RFC 2138 is it. If your
DNS provider doesn't support RFC 2136 it seems hard to imagine you could
convince them to adopt a newly invented ACME DNS update scheme.

- cpu

On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <
[email-masked]> wrote:

>>> of
>> This is out of scope for our WG, but since we are looking at
>> rechartering, it could be brought within scope.
>>
> records on DNS servers. Most DNS server softwares support RFC 2136 out of
> the box. We just have to define a protocol to use (-> RFC 2136) in the ACME
> client.
>
>

---

From: Alan Doherty <[email-masked]>
Date: Wed, 05 Jul 2017 02:08:28 +0100

+1

agreed the acme client design (plugins/modules/supported server architectures etc) should really be down to the implementors/designers

as some smaller ones will only talk acme + http-01 + 1 specific server (say acme client built into server/device)

others may offer many/all auth mechanisms and server architectures (and dns apis)

the WG is realy concerned with the api (and CA server reactions (and expectation of responses)
the myriad clients should handle the third side or the triangle

client <--> acme-ca  <----> client selected 3rd party 
client <-----out of scope-> client selected 3rd party

(3rd party as the webserver or dns provider can be entirely separate) 

At 15:28 04/07/2017  Tuesday, Daniel McCarney wrote:
>I agree with the others that have shared the opinion that this is outside of the scope of ACME and this WG.
>
>In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client.
>
>
>That's exactly right. At least one ACME client (Certbot) has been working on support for RFC 2136 (<https://github.com/certbot/certbot/pull/4701>https://github.com/certbot/certbot/pull/4701) in addition to one-off provider specific DNS APIs.
>
>If you need a generic way to update DNS dynamically RFC 2138 is it. If your DNS provider doesn't support RFC 2136 it seems hard to imagine you could convince them to adopt a newly invented ACME DNS update scheme.
>
>- cpu
>
>On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <<mailto:[email-masked]>[email-masked]> wrote:
>
>
>In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client.
>
>
><mailto:[email-masked]>[email-masked]

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 6 Jul 2017 10:40:14 +0200

You think there should be a proprietary plug-in for any combination of 
DNS-provider <-> ACME-client?

Creating DNS challenges on the fly makes things quite complicated. 
Another way to circumvent the whole challenge protocol for DNS would be 
to let the ACME-client create a static RSA-key-pair an publish the 
public key in die ACME-TXT-record. The ACME-client connects to the 
CA-server via TLS with it's private key and the CA-server just checks if 
the public key in the _acme-challenge.xxx.xxx TXT-record matches the 
private key of the TLS connection.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jul 2017 12:14:49 +0000

> You think there should be a proprietary plug-in for any combination of DNS-
> provider <-> ACME-client?

The question is backwards.

Does there have to be an open standard for any DNS provider/ACME client?

There is an important distinction.

---

From: Patrick Figel <[email-masked]>
Date: Thu, 6 Jul 2017 14:19:20 +0200

> DNS-provider <-> ACME-client?

The best case would be RFC 2138, but that's not something that can be
enforced.

> private key of the TLS connection.

I don't think this option is viable in the Web PKI today, given current
CA/B Forum policies. The Baseline Requirements state that either a
Random Value or a (single-use) Request Token must be part of the DNS
record used for validation.

I'm inclined to agree that some sort of key-based validation would be
beneficial both from a UX perspective and in order to avoid situations
where API keys for DNS servers are stored on web servers for no reason
other than challenge validation. Naturally, demonstrating ownership of a
key that's published in the DNS is not quite the same thing as
demonstrating the ability to change records on demand, given that keys
can leak, but the same can be said for API keys. I would say that a
situation where the attacker has the ability to issue a certificate is
preferable to one where they have both the ability to issue a
certificate *and* change DNS records at will, saving them the trouble of
finding some other way to intercept traffic.

Do other WG members feel similar to this, and should this be brought up
on the CA/B Forum mailing list?

Patrick

>> agreed the acme client design (plugins/modules/supported server
>> architectures etc) should really be down to the implementors/designers
>>
>> as some smaller ones will only talk acme + http-01 + 1 specific server
>> (say acme client built into server/device)
>>
>>> I agree with the others that have shared the opinion that this is
>>> outside of the scope of ACME and this WG.
>>>
>>> records on DNS servers. Most DNS server softwares support RFC 2136
>>> out of the box. We just have to define a protocol to use (-> RFC
>>> 2136) in the ACME client.
>>>
>>>
>>> That's exactly right. At least one ACME client (Certbot) has been
>>> working on support for RFC 2136
>>> (<https://github.com/certbot/certbot/pull/4701>https://github.com/certbot/certbot/pull/4701)
>>> in addition to one-off provider specific DNS APIs.
>>>
>>> If you need a generic way to update DNS dynamically RFC 2138 is it.
>>> If your DNS provider doesn't support RFC 2136 it seems hard to
>>> imagine you could convince them to adopt a newly invented ACME DNS
>>> update scheme.
>>>
>>> - cpu
>>>
>>> On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc.
>>> Informatics <<mailto:[email-masked]>[email-masked]> wrote:
>>>
>>>
>>> records on DNS servers. Most DNS server softwares support RFC 2136
>>> out of the box. We just have to define a protocol to use (-> RFC
>>> 2136) in the ACME client.
>>>
>>>

---

From: Alan Doherty <[email-masked]>
Date: Fri, 07 Jul 2017 02:56:51 +0100

At 09:40 06/07/2017  Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
>You think there should be a proprietary plug-in for any combination of DNS-provider <-> ACME-client?

not at all
(only mentioned plugin as many acme clients use separately maintained plugins for each/every challenge type (as thats how they roll)
obviously monolithic ones such as the LE clients add support for whatever dns-providers they wish themselves
but as with all challenge types having an optional (call user provided script X to update dns/http/etc is worthwhile so people can roll their own)

>Creating DNS challenges on the fly makes things quite complicated. Another way to circumvent the whole challenge protocol for DNS would be to let the ACME-client create a static RSA-key-pair an publish the public key in die ACME-TXT-record. The ACME-client connects to the CA-server via TLS with it's private key and the CA-server just checks if the public key in the _acme-challenge.xxx.xxx TXT-record matches the private key of the TLS connection.

I disagree its no more/less easy http challenge on-the-fly
I suspect Im not the only one running my own private and acl'd off from internet, api on my dns master that receives updates, edits the zone and responds when complete (to avoid exposing a public api that may be brute forced)
and I run a (3rd party) acme(letsencrypt) client that calls my client-side-script for each challenge (these talk to my private api on the master dns server)

all im saying is there are 3 sides to the conversation

client <1> acme-server <2> dns/http/other-auth-system <3> client

I think acme should only codify the communication on the two sides that the acme-server converses on
as client developers can decide to support/neglect as many (or few) auth types and http/dns/other providers as they like

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Fri, 7 Jul 2017 07:04:27 +0200

> as client developers can decide to support/neglect as many (or few) auth types and http/dns/other providers as they like

A lot of DNS server providers do not allow to modify the zones on the 
fly. My DNS server provider e.g. uses a hidden primary DNS for security 
reasons. Changing zones is only possible manually via the web-interface. 
A lot of other DNS server providers limit the update rate or use 
timeouts. DNS was explicitly planned as a non-real-time system. In that 
cases e.g. CertBot runs always in timeouts and cannot work 
automatically. A static key in the DNS zone would solve that problem.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 7 Jul 2017 07:10:09 +0200

Just a caution that configuration for 2138 is not always straight
forward and in implementation and deployment sometimes has interactions
with other functions.  I suggest that someone who really wants to do the
standardization here install a version of opendnssec and get things
working with that code running.  Documenting those steps would prove
useful (he says having chosen another form of auth, having been down
this road).

Eliot

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Fri, 7 Jul 2017 07:28:23 +0200

> useful (he says having chosen another form of auth, having been down

After the information of my DNS server provider not having any interface 
for automated operations I have given up the RFC 2136 approach. In my 
opinion a solution with dynamic records is way to complicated. The 
easier solution is if every ACME-client creates a static asymmetric key 
pair. The operator can add the public key manually to the DNS records 
and the ACME-client uses the private key for authorization with the CA.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Jul 2017 14:01:26 +0300

On Fri, Jul 07, 2017 at 07:04:27AM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> 
> A lot of DNS server providers do not allow to modify the zones on the fly.
> My DNS server provider e.g. uses a hidden primary DNS for security reasons.
> Changing zones is only possible manually via the web-interface. A lot of
> other DNS server providers limit the update rate or use timeouts. DNS was
> explicitly planned as a non-real-time system. In that cases e.g. CertBot
> runs always in timeouts and cannot work automatically. A static key in the
> DNS zone would solve that problem.

However, CABForum BRs (which all public CAs are required to abide by)
prohibit static keys in DNS (funkily enough, BRs seem to allow static
keys in WHOIS).

I think if one wanted to change that, next step would be to make a
fleshed out proposal for such validation method and a through security
analysis of it (in order to guide possible changes to BRs).

As note:

The time it takes from a CABForum member positing a ballot with two
endorsers to incorporation of said ballot (if ballot passes vote and
there are no IPR issues) into BRs is about 7 weeks. Of course, with
complicated ballots, it takes a lot of time to prepare the ballot.

-Ilari