Re: [Acme] dns-01 challenge limitations
On Friday, September 11, 2020 7:06 PM, Michael Richardson wrote: > Simon Ser wrote: > > dns-01 requires the ACME client to complete the challenge by updating a > DNS > > record. This is bothersome because this often requires interacting with > the > > DNS registry operator. This is typically done via vendor-specific APIs, > with > > access control handled via vendor-specific means (tokens, public keys, > > etc). > > I guess if you've hosted your zone with the registrar, then that might be > true. my opinion: Don't do that. > > Host your own zone, and/or use Dynamic DNS update (RFC3007), which is mature > technology. > There are some annoyances with TSIG until you realize that the key name > really matters. That sounds like the most reasonable way to solve the dns-01 challenge indeed. The self-hosted zome can even be limited to just _acme-challenge. I'm still wondering whether dns-01 is an absolutely necessary evil (see other replies). > > 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. > > So, this would be be a client key challenge. > This would not be dns-01. It could certainly work, but it would be a new > effort. > Maybe we could use SIG(0), I'm not sure. Yes, this wouldn't be dns-01 or dns-02, it would be a completely separate thing. > The question would be whether or not it would get implemented. Yes, this is why I'm writing to this mailing list. Maybe I should've CC'ed some Let's Encrypt specific mailing list as well. > > Are there specific reasons why dns-01 requires updating a DNS record? > > Yes, because it proves you control the zone. Right, but there could be other ways to prove this as well. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
> On Friday, September 11, 2020 4:26 PM, Ryan Sleevi > wrote: > > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß > > 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
Re: [Acme] dns-01 challenge limitations
On Friday, September 11, 2020 3:41 PM, Patrik Wallström wrote: > Simon Ser skrev den 2020-09-11 kl. 15:25: > > > Hi, > > On Friday, September 11, 2020 3:17 PM, Felipe Gasper > > fel...@felipegasper.com wrote: > > > > > > On Sep 11, 2020, at 9:08 AM, Simon Ser cont...@emersion.fr 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. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
Hi, On Friday, September 11, 2020 3:17 PM, Felipe Gasper wrote: > > On Sep 11, 2020, at 9:08 AM, Simon Ser cont...@emersion.fr 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). Thanks, Simon ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
Hi, On Friday, September 11, 2020 3:13 PM, Philipp Junghannß wrote: > I have asked that question in the LE forum iirc the problem is that > someone could place that record once and as long as someone doesnt > look at it all the time one can easily miss the fact that someone can > create wildcards and stuff for that domain, so the point is to prove > that dns access is given at the time of issuance. If someone has once write access to the DNS, they can set an acme-challenge record, redirect all requests, and issue wildcard certs. That would be easy to miss, too. > you could maybe use a different DNS Server which has a better API, > and potentially even can be used by ACME. The issue at hand isn't that a particular DNS registry operator isn't supported by a particular ACME client. What I want to fix is the need for all ACME clients to support all DNS registry operators. Thanks, Simon ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] dns-01 challenge limitations
Hi all, I've been working on an ACME client acting as a TLS termination proxy. In order to retrieve wildcard certificates from the Let's Encrypt ACME servers, support for the dns-01 challenge is required. dns-01 requires the ACME client to complete the challenge by updating a DNS record. This is bothersome because this often requires interacting with the DNS registry operator. This is typically done via vendor-specific APIs, with access control handled via vendor-specific means (tokens, public keys, etc). I understand that it's difficult for ACME clients to prove that they are authorized to obtain wildcard certificates. However, have other alternatives been considered? 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. Are there specific reasons why dns-01 requires updating a DNS record? Thanks, Simon Ser (CC mholt, I figured you might be interested in this for Caddy too) ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
