> On Friday, September 11, 2020 4:26 PM, Ryan Sleevi <[email protected]> > wrote: > > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß > > <[email protected]> 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). _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
