Subject: [Acme] Assisted-DNS challenge type

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 22 Jan 2018 17:09:53 -0800

Inspired by a thread on Let's Encrypt's community forum
(https://community.letsencrypt.org/t/suggestion-lets-encrypt-operated-txt-only-dns-hosting-for-dns-challenges/50399/1),
I'd like to propose a new challenge type, "assisted-dns-01".

The existing DNS challenge is good for a number of reasons, but it has a
couple of key problems:
 - It's hard to automate, and many DNS providers may offer no automation
at all.
 - Automating it may mean putting DNS credentials on a web frontend,
which may increase risk.

To fix that, the CA could assist the user by providing narrowly-scoped
DNS hosting: It would serve only TXT records used in validating DNS
challenges. The CA instruct subscribers to delegate the _acme-challenge
subdomain to a subdomain of the CA's hosted DNS domain. For instance, if
a subscriber has account number 1234, the CA would say: Please deploy a
CNAME record like so:

_acme-challenge.example.com. CNAME 1234.challenges.ca.example.net.

The assisted-dns-01 challenge would then be validated like dns-01,
except: As the first step in validation, the CA would deploy the
expected TXT value at 1234.challenges.ca.example.net. Then the CA would
continue to look up "TXT _acme-challenge.example.com." In a way,
fetching final TXT record would be a formality: the CA could in theory
stop once it saw the CNAME pointed at the right location, though most
likely abiding by the terms of the BRs would require following the
formal lookup steps.

This challenge has the big advantage that subscribers only need to do a
one-time CNAME setup, and renewals can be reliably automated without
requiring that renewing systems have permission to update DNS. In
effect, the CNAME record would act like a long-term delegation
permitting the CA to issue continuously for the base domain.

The challenge object would contain a field telling the client what the
CNAME target should be. Based on this, clients can check the existing
DNS and prompt a user to add the CNAME if needed, or continue
automatically if it's already present.

Example assisted-dns-01 challenge:

{
  "type": "assisted-dns-01",
  "token": "abc123",
  "cnameTarget": "1234.challenges.ca.example.net.",
}

If people think this challenge type has merit, my proposal is that it be
part of an extension document, not part of the core ACME doc.

Credit to Joona Hoikkala, Matt Nordhoff, and forum user @_az for helping
to develop this concept.

---

From: Alex Zorin <[email-masked]>
Date: Tue, 23 Jan 2018 13:17:49 +1100

Sounds great, this would lift a huge burden lifted from users. As noted by Joona in the "Trust and security" thread, foreseeable automation options for the existing DNS challenge are really lacking, and improvements there would either require a lot of retooling by e.g. DNS hosts, or convoluted solutions like end-users having to run their own ACME-DNS kinds of services.

One potential issue: there are number of DNS providers that do not permit underscores in CNAME (or NS for that matter) labels, whilst permitting them in TXT labels. It may be worthwhile to do a survey of DNS hosts of domains using Let's Encrypt to check what this looks like in the real world.

On Tue, Jan 23, 2018, at 12:09 PM, Jacob Hoffman-Andrews wrote:
> In

I can imagine that this introduces a new risk of domain administrators "forgetting" about having made a long-term delegation of  _acme-challenge to the CA and unwittingly authorize an account key to issue certificates for any name longer than intended. Any need to mitigate this?

---

From: Zach Shepherd <[email-masked]>
Date: Tue, 23 Jan 2018 04:36:37 +0000

> > In effect, the CNAME record would act like a long-term delegation

> I can imagine that this introduces a new risk of domain
> administrators "forgetting" about having made a long-term delegation
> of  _acme-challenge to the CA and unwittingly authorize an account
> key to issue certificates for any name longer than intended. Any need
> to mitigate this?

It seems like each existing challenge type requires a user to prove
continued ownership of the identifier to receive authorization.

This challenge, however, is different: an action serves as proof of
ownership until it is un-done.

Hypothetical: how would we feel about an assisted-http-01 challenge
that, analogously, provides users with an address to use in an HTTP
redirect for resources under /.well-known/acme-challenge?

The CA instruct subscribers to delegate the /.well-known/acme-challenge
directory to a subdomain of the CA's hosted DNS domain.

The assisted-http-01 challenge would then be validated like http-01,
except: As the first step in validation, the CA would deploy the
expected resource at 1234.challenges.ca.example.net.

Then the CA would continue to perform a GET operation on the usual
resource "GET example.com/.well-known/acme-challenge/...", which
would redirect to 1234.challenges.ca.example.net/...

In a way, fetching final resource would also be a formality: the CA
could in theory stop once it saw the redirect pointed at the right
location, though most likely abiding by the terms of the BRs would
likewise require following the formal lookup steps.

I think this hypothetical assisted-http-01 is a fair analog, but does
not seem like something we would want to support. And given that, I'm
not convinced the added complexity of automation or difficulty of
protecting DNS credentials are sufficient to justify assisted-dns-01.

Zach

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Jan 2018 09:09:34 +0200

> permitting the CA to issue continuously for the base domain.

I came up with very similar method when trying to figure out how the
Amazon Certificate Manager DNS challenge works. It has similar
"standing authentication" property, and yet needs to comply with the
BRs.

-Ilari

---

From: Niklas Keller <[email-masked]>
Date: Tue, 23 Jan 2018 09:09:48 +0100

> "standing authentication" property, and yet needs to comply with the

This seems very much like a circumvention of the BRs. Either this
circumvention should be forbidden, because it effectively doesn't re-prove
ownership, or the BRs can be changed to allow permanent authorization for
accounts, then we don't need the CA to host anything like that.

We could then allow e.g. an account key thumbprint to authorize a specific
account key to request certificates. Using the account key would allow that
key to request those certificates from any ACME supporting CA, not just
one. A binding could be introduced, but I guess CAA already solves that.

Regards, Niklas

---

From: Thomas Lußnig <[email-masked]>
Date: Tue, 23 Jan 2018 10:12:39 +0100

Hi,

instead of an FIXED cname that does not ensure that the requestor 
possess access to the dns.
I would prefer to use an static TXT record whith the Account Key hashed. 
This would prove that
only an person possesing an specified private key is allowed to request.
Or to use TLSA record to verify that the requested zertificate would be 
valid for dane.
This would weaken the DNS-SEC Requirement for DANE but would not 
introduce an weakness compared
to the suggested solution.

Gruß Thomas

Am 2018-01-23 09:09, schrieb Niklas Keller:
>>> _acme-challenge.example.com [1]. CNAME
>> 1234.challenges.ca.example.net [2].
>>> 
>>> expected TXT value at 1234.challenges.ca.example.net [2]. Then the
>> CA would
>>> continue to look up "TXT _acme-challenge.example.com [1]." In a
>> way,
> circumvention should be forbidden, because it effectively doesn't
> re-prove ownership, or the BRs can be changed to allow permanent
> authorization for accounts, then we don't need the CA to host anything
> like that.
> 
> We could then allow e.g. an account key thumbprint to authorize a
> specific account key to request certificates. Using the account key
> would allow that key to request those certificates from any ACME
> supporting CA, not just one. A binding could be introduced, but I
> guess CAA already solves that.
> 
> Regards, Niklas
> 
> Links:
> ------
> [1] http://acme-challenge.example.com
> [2] http://1234.challenges.ca.example.net
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Jörn Heissler <[email-masked]>
Date: Tue, 23 Jan 2018 12:22:34 +0100

On Tue, Jan 23, 2018 at 10:12:39 +0100, Thomas Lußnig wrote:
> instead of an FIXED cname that does not ensure that the requestor possess
> access to the dns.

From what I understand, this discussion basically is the same as e.g.
https://github.com/ietf-wg-acme/acme/issues/88

It all boils down to
"I don't want dynamic challenges, I want static authorization."

-----BEGIN ADVOCATUS DIABOLI-----
I hereby propose that ACME is scrapped and replaced by the following workflow:

- Create asymmetric key pair (may be reused for multiple domain names!)
- Create DNS record: _acme-key.<domain>. TXT "<hfunc>:<hex(hash(der(pubkey)))>"
- Create key + csr (CN/SAN <domain>)
- POST json([CSR, pubkey, signature]) to https://<cadomain>/acme/issue
- CA fetches pubhash from DNS, verifies the request and replies with the cert.

I just reduced the ACME protocol to 5 lines :-]
No more bothering with jws, accounts, nonces or challenges.
-----END ADVOCATUS DIABOLI-----

More serious now. Why does ACME use challenges? Are there any benefits
that justify the complexity of the protocol?
When offering an easier way (see above), nobody will ever bother using
the complex way again and those benefits no longer apply.

Cheers
Joern Heissler

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 23 Jan 2018 16:37:44 +0000

> This challenge has the big advantage that subscribers only need to do a one-
> time CNAME setup, and renewals can be reliably automated without requiring
> that renewing systems have permission to update DNS. In effect, the CNAME
> record would act like a long-term delegation permitting the CA to issue
> continuously for the base domain.

Yes, not having to validate domains saves customers a lot of time and effort!
See BR validation methods #1 and #5 for more information!! 😊

Your proposed method defeats one of the goals of the BR domain control 
validation requirements, which is to demonstrate control at time of validation, 
not just as some previous time in the past.  That's why the existing, approved
validation methods require random numbers to guarantee the validation is
fresh and not based on some previous validation.

If control at some time in the past is sufficient, you can just re-use the previous 
validation, which is allowed in some circumstances (see the BRs).

-Tim

---

From: Thomas Lußnig <[email-masked]>
Date: Tue, 23 Jan 2018 17:41:58 +0100

Yes and if you avoid the random token in the primary location,
you can use the public account key announced in the dns also as static 
prove.

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 17:47:43 -0600

> On Jan 22, 2018, at 7:09 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> In a way, fetching final TXT record would be a formality: the CA could in theory

In the scheme you propose here, the optics of the situation may be a concern.  The fact that the lookup is a formality because the CA directly altered the the records opens the door for objections and ballots to revise the “work around”.

Why not operate the special limited DNS infrastructure in a way that even a non-CA party could theoretically own/manage that infrastructure in a manner that doesn’t require the CA itself to trust the third party?

Have the target CNAME zones assigned at random and bound to an account key or similar, standardize an API for requests for new CNAME target labels to be assigned for use and for updates to be executed by the ACME client directly.  In other words, don’t have the CA modify the target CNAME label’s TXT records — let the ACME client do it.

Provide an API which lets any ACME client user apply for a new random target CNAME label, perhaps in an account-id hierarchy, bound to a cryptographic key for updates/adds of TXT records in that zone or on that label and then you can run it or any other party trusted by the ACME client who makes the delegation to the remote label can be chosen.

The fetching by the CA validation logic in this case is no longer a formality nor is it any kind of stacked-deck farce and it is no longer strictly necessary that the dynamic limited DNS provider even be the CA.  (Albeit the dynamic limited DNS provider DOES need to be a trustworthy party AND a party trusted by the subscriber.)

Technologically, the merits of my proposed change are limited.  In terms of the optics, this opens the door to real separation from the CA as well as has the client demonstrating something more akin to material control of the target dynamic zone, reducing arguments that the mechanism is an end-run of any kind.

---

From: Alan Doherty <[email-masked]>
Date: Thu, 25 Jan 2018 00:38:35 +0000

but then if example.com sets up such a record

pointed at letsencrypt (or other)

how does my client (or theirs)
ever prove which is actually a legitimate applicant for certs for example.com??

the idea of a challenge is its only known to the client that requested the cert
thus has to be returned to the CA by the client via DNS/http whatever

now if you were to suggest the CA(or any other third party) provide a dns api to modify/update 1234.challenges.whoever.example.net. txt records

thus client receives challenge modifies the dynamic zone 1234.challenges.whoever.example.net.

thus proves to acme server following the cname it does control the zone that cnamed there

if so normal dns-01 does follow cnames? (dosn't it)

thus all you need to do is find a dns provider thats api is supported by your chosen letencrypt client
delegate a subdomain to them challenges.yourdomain.net, cname challenges to that zone and get your le client to update the txt when challenges received?

or just delegate directly _acme-cahallenges.yourdomain.net to that provider cut out the cnames entirely ;)

At 01:09 23/01/2018  Tuesday, Jacob Hoffman-Andrews wrote:
>Inspired by a thread on Let's Encrypt's community forum (https://community.letsencrypt.org/t/suggestion-lets-encrypt-operated-txt-only-dns-hosting-for-dns-challenges/50399/1), I'd like to propose a new challenge type, "assisted-dns-01". The existing DNS challenge is good for a number of reasons, but it has a couple of key problems: Â - It's hard to automate, and many DNS providers may offer no automation at all. Â - Automating it may mean putting DNS credentials on a web frontend, which may increase risk. To fix that, the CA could assist the user by providing narrowly-scoped DNS hosting: It would serve only TXT records used in validating DNS challenges. The CA instruct subscribers to delegate the _acme-challenge subdomain to a subdomain of the CA's hosted DNS domain. For instance, if a subscriber has account number 1234, the CA would say: Please deploy a CNAME record like so: _acme-challenge.example.com. CNAME 1234.challenges.ca.example.net. The assisted-dns-01 challenge would th
en be validated like dns-01, except: As the first step in validation, the CA would deploy the expected TXT value at 1234.challenges.ca.example.net. Then the CA would continue to look up "TXT _acme-challenge.example.com." In a way, fetching final TXT record would be a formality: the CA could in theory stop once it saw the CNAME pointed at the right location, though most likely abiding by the terms of the BRs would require following the formal lookup steps. This challenge has the big advantage that subscribers only need to do a one-time CNAME setup, and renewals can be reliably automated without requiring that renewing systems have permission to update DNS. In effect, the CNAME record would act like a long-term delegation permitting the CA to issue continuously for the base domain. The challenge object would contain a field telling the client what the CNAME target should be. Based on this, clients can check the existing DNS and prompt a user to add the CNAME if needed, or continue a
utomatically if it's already present. Example assisted-dns-01 challenge: { Â  "type": "assisted-dns-01", Â  "token": "abc123", Â  "cnameTarget": "1234.challenges.ca.example.net.", } If people think this challenge type has merit, my proposal is that it be part of an extension document, not part of the core ACME doc. Credit to Joona Hoikkala, Matt Nordhoff, and forum user @_az for helping to develop this concept.Â Â Â  _______________________________________________ Acme mailing list [email-masked] https://www.ietf.org/mailman/listinfo/acme