This is the least secure option and most likely to be deprecated going forward. Sending an email, even to the IANA-defined boundaries, is simply not a substitute for proof of domain control.
On Sun, Sep 13, 2020 at 5:17 AM Philipp Junghannß <teamhydro55...@gmail.com> wrote: > maybe one could make it so an email specific to the domain that is > verified could be used instead to just screw the entire DNS thing? I mean > CAs have used e-Mail based issuance over the address in the whois (no > longer practical due to increase of whois privacy by default) or the > standardized hostmaster etc addresses. that way any given acme client would > only need access to the inbox of that specific mail which probably is a > whole lot easier than DNS stuff. > > Am So., 13. Sept. 2020 um 11:13 Uhr schrieb Simon Ser <cont...@emersion.fr > >: > >> > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi < >> ryan-i...@sleevi.com> wrote: >> > >> > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß < >> teamhydro55...@gmail.com> 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
