Re: [Acme] dns-01 challenge limitations

[Simon Ser <[e-mail]>]

> On Friday, September 11, 2020 4:26 PM, Ryan Sleevi <[e-mail]> wrote:
>
> > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß <[e-mail]> wrote:
> >
> > > problem is obviously also the CA/Browser Forum has certain requirements,
> > > and I guess having access to some kind of direct verification at the time
> > > of issue might be probably one of these.
> >
> > This is the correct answer.
> >
> > While the IETF can certainly explore developing voluntary standards for
> > other methods, the ability for CAs to adopt these methods is limited by CAs
> > customers: the browsers and operating systems that include and use CAs to
> > validate domain names on their behalf.
> >
> > The explicit goal by several browser/OS vendors is to obtain a fresh proof
> > of control over a domain, and reduce/eliminate any caching or reuse.
> > Delegation (by keys or persistent records) is definitely an area of
> > expressed concern.

My take is that in theory it's an understandable goal, but that in practice,
this detoriorates security.

In practice, ACME clients:

1. Have a static, long-term token stored in their configuration file
2. The token is powerful and can update any DNS record in the zone

How come browser/OS vendors are fine with this, but not with a different
approach involving an ACME-specific key?

Sure, since this happens behind the ACME/DNS protocols and is an implementation
detail, this isn't ACME's responsibility anymore. However, because browsers/OS
vendors have this requirement of not allowing delegated proofs, we end up with
a worse situation than necessary.

Ultimately, ACME clients need a way to update DNS records to solve the dns-01
challenge. Ignoring and pushing the problem down to the DNS operators does not
fix the root cause.

If an ACME client needs to prove that they have authority over a DNS zone, they
will need some kind of authorization/key/token or similar, be it
vendor-specific or not. Why not acknowlege this fact and come up with a
reasonable standard?

> > I think the suggest of more uniform APIs for managing DNS is very much in
> > line with those goals, and would help far more than ACME.

Yes, no matter what ACME requires, a standardized API to update DNS records
would be nice. Michael Richardson suggested that such an API (or a subset of)
already exists (via secure DDNS), but isn't supported by most DNS operators
(even if supported by some DNS daemons).

Establishing a new standard involves talking to existing DNS operators, and ask
them to implement the new standard. For them, the new standard wouldn't have a
high enough return on investment: ACME clients already volunteer to implement
each and every proprietary API. Even if a good standard ticking the checkboxes
of RFC 5218 existed, I don't think it would be successful (no "Positive Net
Value" for DNS operators).