Subject: [Acme] Should the DNS challenge be deterministic?

From: Hugo Landau <[email-masked]>
Date: Thu, 12 Nov 2015 07:05:58 +0000

Currently, the DNS challenge uses a random token which changes every
time an authorization is performed.

This seems problematic, however. Changes to DNS can take time to
propagate, and changes to DNS may involve manual intervention.  If an
authorization fails for any reason, the process has to be started again.

This seems like an obstacle to the automated acquisition and renewal of
certificates which ACME is supposed to enable. Since what is ultimately
desired is to authorize an account, wouldn't it make more sense to place
in DNS not a random challenge response, but an unambiguous endorsement
of a given account key to represent the domain? This could be reverified
easily by subsequent authorizations.

Hugo Landau

---

From: Romain Fliedel <[email-masked]>
Date: Thu, 12 Nov 2015 10:11:12 +0100

> authorization fails for any reason, the process has to be started again.

+1
To avoid the cache issue I'm using short TTL but it would be easier if the DNS value was constant for a given account.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Nov 2015 14:25:57 +0200

On Thu, Nov 12, 2015 at 10:11:12AM +0100, Romain Fliedel wrote:
> To avoid the cache issue I'm using short TTL but it would be easier if
> the DNS value was constant for a given account.

I think one would also have to include the endorsed EESPKI (End-Entity
SubjectPublicKeyInfo, a.k.a. the server public key) too (or at least
collision-resistant hash of it)?

That should rarely change, so it should be quasi-constant.

-Ilari

---

From: Hugo Landau <[email-masked]>
Date: Thu, 12 Nov 2015 13:20:01 +0000

> That should rarely change, so it should be quasi-constant.

That works, but I'm not convinced it's necessary. Firstly, doing that
means it would be necessary to change the authorization model so that an
authorization can be valid for only some CSRs, namely CSRs with a
certain subject public key.

There could be some advantages to doing that. For example it would also
make it easier to model the automatic conversion of DANE records into
authorizations, as I wrote previously regarding DNSSEC.

But the current authorization model is that if you can provision DNS
records, you can get a certificate without any particular restrictions
on the subject public key. I don't see how moving to a deterministic
DNS response weakens this?

Binding to the public key would prevent the regular changing of keys. As
it is there's little reason not to generate a new key for each renewed
certificate request unless you're doing end-key pinning.

Hugo Landau

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Nov 2015 18:42:15 +0200

> certain subject public key.

Probably not actually necressary, given that one could have domain
endorse the account keys and account keys endorse the server key.

> authorizations, as I wrote previously regarding DNSSEC.

Well, either the DANE conversion issuance would have to be anonymous,
or one would have DANE just act as restriction on server key.
 
> DNS response weakens this?

Oh yes, the "hack A/AAAA and get a cert".

> certificate request unless you're doing end-key pinning.

Or it is hard to change the key...

-Ilari

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Nov 2015 02:51:13 +0900

On Thu, Nov 12, 2015 at 4:05 PM, Hugo Landau <[email-masked]> wrote:

> propagate,

If the issuer of the DNS challenge flushes its DNS cache and checks with
the authoritative server itself, the propagation de​lay doesn't seem like
an issue. Are there particular issuers/conditions for which you believe the
issuer would have to rely on caching resolvers?

> and changes to DNS may involve manual intervention.  If an
​But isn't that the point?  We're looking for a demonstration that they are
capable of making a specified change.

> easily by subsequent authorizations.
​Can you provide text for what you propose?  I'm having a bit of trouble
parsing your intent.

regards,

Ted​

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

---

From: Romain Fliedel <[email-masked]>
Date: Thu, 12 Nov 2015 19:24:13 +0100

> issuer would have to rely on caching resolvers?

For certain dns provider, you are given the ability to change dns
configuration using an api (eg: ovh.com), but you don't have any guaranty
on the time it will take for the changes to be applied. In my current dns
implementation I had to make sure that the authoritative server where up to
date before submitting the challenge response.

Another approach would be to retry several times on the acme server (let's
say 3 times respectively after 5min, 15min, 1h) before considering the
challenge as failed.

> ​But isn't that the point?  We're looking for a demonstration that they
> are capable of making a specified change.
>

If you really want to change the challenge each time, I would suggest using
a new dns prefix for each challenge (eg: _
acme-challenge_zbn9gshv.example.org).
This would solve the cache issue, and perhaps increase the security as an
attacker would also have to guess the proper prefix.

---

From: Hugo Landau <[email-masked]>
Date: Thu, 12 Nov 2015 21:12:41 +0000

>    an issue. Are there particular issuers/conditions for which you believe
>    the issuer would have to rely on caching resolvers?

This works, but there exist DNS providers where updates to even their
own nameservers take tens of minutes or more, or at least are not
guaranteed to take less than that. These might be quite crummy DNS
providers, but they don't appear to be rare.

Keep in mind that if a challenge fails, the entire authorization is
deemed invalid and must be restarted. So it's very easy to fail an
authorization and have to start over again. I think this property,
combined with the non-determinism of DNS challenges, makes the dns
challenge type impractical as it currently stands.

Moreover, with a deterministic challenge you can renew the authorization
trivially, enabling automatic certificate renewal in the case where
automated connection of /.well-known/acme-challenge or TLS-SNI is
infeasible or more complex. While these cases will hopefully not be
common, endorsing an account key in DNS seems like a simple and
low-maintenance solution.

>    ​Can you provide text for what you propose?  I'm having a bit of trouble

Let's say that the DNS challenge was changed so that the following
format is used:

  _acme-challenge IN TXT "a=<base64 SHA-256 hash of account JWK in
  canonical form>"

This provides essentially equivalent security to trusting unsigned
A/AAAA records. Arguably, the security is marginally higher, since
an entity which can't forge DNS but can MitM all validation queries
going to a server can't get a certificate unless it gets the account
key.

(One alternative might be to use CAA records, but that would have the
potentially undesired side effect of preventing the use of other CAAs,
and while the CAA specification envisions the use of account
identifiers, the purpose of that is to restrict, not to authorize.)

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 12 Nov 2015 14:14:11 -0800

I like the idea, and it generalizes to the other queries. For instance,
you can imagine putting up an HTTP validation file that contains a list
of authorized account keys, with no random token.

However, the CA/B Forum validation requirements currently being
discussed include a requirement for a "Random Token." So we'd need to
convince them to add language that would allow something like an
authorized account key.

---

From: Hugo Landau <[email-masked]>
Date: Fri, 13 Nov 2015 01:25:35 +0000

> convince them to add language that would allow something like an

That's unfortunate. Is the language unambiguous enough that the 'random
token' must be per-authorization, rather than e.g. a random token
generated at account generation time (which could be passed as well as
the account key)?

If there's no way around this, it seems like it might still be useful
to specify a deterministic DNS challenge type so that a specification
is available for implementation if they change their minds.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 13 Nov 2015 09:26:09 +0200

> generated at account generation time (which could be passed as well as

By my reading, the applicable case is "a value specified by CA to the
Applicant that exhibits at least 112 bits of entropy". I don't see
any discussion wheither it is per-request or per-token. And the other
case would imply that it doesn't even have to be unknown to the
applicant (that case explicitly says so).

There also seems to be second method, but it would require pre-
generating the server private key.

-Ilari

---

From: Romain Fliedel <[email-masked]>
Date: Fri, 13 Nov 2015 15:00:48 +0100

> authorized account key

perhaps the use of a random dns prefix would be sufficient ?

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 13 Nov 2015 17:29:51 +0200

> perhaps the use of a random dns prefix would be sufficient ?

I don't think that would help the present problem. Specifically:
The client would want to compute the response to the challenge:
1) Without contacting the CA.
2) Without knowledge of server keys (including public key).

The reason for this is that it can take annoyingly long time
after challenge becomes known until it is reliably available.
And these delays are not from DNS caching (one can do uncached
fetches at cost of increased load).

And for the second requirement, having to know server keys
would create problems with key rotation (apparently folks think
keys should be rotated by default, and those that don't want
that, e.g. due to using HPKP or DANE can disable key rotation).

-Ilari