Re: [Acme] dns-01 challenge limitations

[Ryan Sleevi <[e-mail]>]

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ß <[e-mail]>
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 <[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).
>>
>>