Re: [Acme] dns-01 challenge limitations

[Patrik Wallström <[e-mail]>]

Simon Ser skrev den 2020-09-11 kl. 15:25:
> Hi,
> 
> On Friday, September 11, 2020 3:17 PM, Felipe Gasper <[e-mail]> wrote:
> 
>>> On Sep 11, 2020, at 9:08 AM, Simon Ser [e-mail] wrote:
>>> For instance, it would be possible to require users to add a short public key
>>> in a DNS TXT record, then ask the ACME client to sign challenges with that key.
>>> Something like this would significantly ease the development of ACME clients.
>>
>> This would seem to introduce a new vector--key compromise--for being
>> able to impersonate the domain, wouldn’t it?
>>
>> Such an authz method would be proving not access to the domain
>> itself, but access to the key, and would be vulnerable to local
>> misconfigurations. It seems thus not dissimilar to the erstwhile
>> problem with tls-sni-01/02.
> 
> Right now ACME clients need vendor-specific authorizations, like API
> tokens. If the DNS registry operator's token is leaked, much worse
> things can happen than just being able to issue wildcard certificates
> (since the token provides write access to DNS records).

The missing piece of this puzzle is a standardized API for registrars
(or DNS operators), where changes can be made for a zone at a registrar.
Much like registry changes coming from registrars to a registry using
EPP. Many attempts has been made for this, but for some reason,
registrars like their lock-in models.

Perhaps some day there will be an attempt at both creating a really good
open source zone editor that will be adopted by registrars and other DNS
opreators, that also implements an API that is generally accepted. Then
perhaps this API could become a standard for interacting at least with
DNS operators for changing the content of a zone. (No, and I don't think
RFC 2136 is good enough for this.)

For now, this is for many ACME clients a manual step. If you run your
authoritative DNS service locally in your network, perhaps you could
look into any options for automatically update the zone content.