Re: [Acme] dns-01 challenge limitations

[Simon Ser <[e-mail]>]

On Friday, September 11, 2020 3:41 PM, Patrik Wallström <[e-mail]> wrote:

> 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.

I agree a standardized API for DNS operators would be nice, but it's a
pretty massive task. I don't see this happening anytime soon, no matter
how hard I try.

For this reason, I think a different approach would be desirable.