Subject: [Acme] Feature Request: dns-02

From: Tobias Erichsen <[email-masked]>
Date: Wed, 12 Sep 2018 08:55:50 +0000

Hello everyone,

there have been various feature proposals on the Let's Encrypt community forum and also at least one here on this mailing-list
(https://www.ietf.org/mail-archive/web/acme/current/msg00641.html) to implement a version of the dns challenge that is
less complex than the current solution where a generic client needs to implement a large amount of different APIs  to cover
all the DNS-providers in the wild, some of which don't even provide automatable APIs...

I'm really curious to learn about the reasons why those proposals have been ignored.  Perhaps I overlocked some explanation,
but I did not discover any yet...

One defined TXT-Record for each ACME-provider like Let's encrypt for example which contain the SHA-512 hash of the publid key,
or the hash of the account-name should really suffice to prove the domain-control when trying to renew certificates...  During
the ACME renewal, a cryptographic exchange of a token should prove the control over ACME public/private.

Is there anything I have overlooked which would be a reason to block the introduction of such dns-02 challenge?

Best regards,
Tobias

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Sep 2018 13:29:12 +0300

> Is there anything I have overlooked which would be a reason to block the introduction of such dns-02 challenge?

Yes, you overlooked CABForum Baseline Requirements.

These requirements require DNS validation to return one of:

- Public key (hash) + timestamp, valid at most _30_ days.
- Public key (hash) + nonce, valid _once_.
- Random >=128-bit Value specified by CA, valid _once_.

However, due to the fact that CNAME and NS are just magic in DNS,
those are chased and as such, from point of server operator there
would also be:

- CNAME to target specified by CA, valid _until_ _removed_.

This is implemented by at least one CA (Amazon, only issues certificates
for cloudfront and such). For proposal of such mode in ACME, search the
mailing list archives for "assisted-DNS".

Another way as consequence of CNAME and NS records being chased is
CNAME'ing the _acme-validation to another nameserver (possibly self-
hosted), that does properly support automatable API.

If you have a single-server setup, one can set up DNS on that server
to handle validation like follows:

_acme-validation.firstdomain.example CNAME bar.acme.firstdomain.example
_acme-validation.foo.firstdomain.example CNAME bar.acme.firstdomain.example
_acme-validation.seconddomain.example CNAME bar.acme.firstdomain.example
acme.firstdomain.example NS firstdomain.example
firstdomain.example A <ipv4 address>
firstdomain.example AAAA <ipv6 address>

Then configure a DNS authoritative for acme.firstdomain.example on the
server, with API access. The validation requests for firstdomain.example,
foo.firstdomain.example and seconddomain.example will be sent to that
server as TXT requests for bar.acme.firstdomain.example.

If you want to actually cryptographically secure the domain, then the DNS
server on the server must be DNSSEC-capable, you need also DS record for
acme.firstdomain.example, and also CAA validationmethods only allowing
dns-01 on each domain apex, all DNSSEC-enabled. If this is not done, then
the domains will be vulernable to usual DNS and routing attacks.

-Ilari

---

From: Alan Doherty <[email-masked]>
Date: Wed, 12 Sep 2018 14:03:17 +0100

i think its because acme is designed to be interactive/interrogative proof of control

as opposed to proof the acme client had control at some point in the past (but no guarantee its still the case)

At 09:55 12/09/2018  Wednesday, Tobias Erichsen wrote:
>Content-Language: de-DE
>Content-Type: multipart/alternative;
> boundary="_000_21603AF28BEB014F89BED60814E8E14E3F1CE82Aexchange2010wob_"
>
>Hello everyone,
> 
>there have been various feature proposals on the Let’s Encrypt community forum and also at least one here on this mailing-list
>(<https://www.ietf.org/mail-archive/web/acme/current/msg00641.html>https://www.ietf.org/mail-archive/web/acme/current/msg00641.html) to implement a version of the dns challenge that is
>all the DNS-providers in the wild, some of which don’t even provide automatable APIs…
> 
>I’m really curious to learn about the reasons why those proposals have been ignored.  Perhaps I overlocked some explanation,
>but I did not discover any yet…
> 
>One defined TXT-Record for each ACME-provider like Let’s encrypt for example which contain the SHA-512 hash of the publid key,
>or the hash of the account-name should really suffice to prove the domain-control when trying to renew certificates…  During
>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme