Re: [Acme] dns-01 challenge limitations
Ilari Liusvaara wrote: >> 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 think the current best way is to have _acme-challenge be a CNAME > pointing to zone served by single master with no slaves that accepts > DNS UPDATE with TSIG HMAC-SHA256 authentication for ACME client to > update the records. That's precisely what I do. I do it because bind9 does not do well when zones are managed by updates as well as manual edits. So I CNAME to a single (sub)zone where it is all updates. > The single master is more than reliable enough for the purpose (as > there should be donzens of retries spread over time for renewal before > the certificate expires) and eliminates the propagation times. I do have multiple masters, and I mean to program a query to all NS to see if the update has propogated, but for now, I "sleep(30)", which is definitely sub-optimal in the best cases, and a failure if there are problems. So far, it works great. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
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. > 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. The question would be whether or not it would get implemented. > Are there specific reasons why dns-01 requires updating a DNS record? Yes, because it proves you control the zone. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
On Fri, Sep 11, 2020 at 03:41:08PM +0200, Patrik Wallström wrote: > > > 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.) One another problem is that even if one has programmatic API, the DNS service has many servers (due to being intended for high-reliability slow-update serving, not low-reliability fast-update serving), with potentially painfully slow propagation times. > 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 think the current best way is to have _acme-challenge be a CNAME pointing to zone served by single master with no slaves that accepts DNS UPDATE with TSIG HMAC-SHA256 authentication for ACME client to update the records. The single master is more than reliable enough for the purpose (as there should be donzens of retries spread over time for renewal before the certificate expires) and eliminates the propagation times. -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
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. 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. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
Simon Ser skrev den 2020-09-11 kl. 15:25: > 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). 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. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
well Certificate transparency is one something should maybe keep notifications for. Also I can understand the problem, but I have not decided the outcome, I merely stated what I got as an answer back then. 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. Am Fr., 11. Sept. 2020 um 15:21 Uhr schrieb Simon Ser : > Hi, > > On Friday, September 11, 2020 3:13 PM, Philipp Junghannß < > teamhydro55...@gmail.com> 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
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
Re: [Acme] dns-01 challenge limitations
> On Sep 11, 2020, at 9:08 AM, Simon Ser 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. -F ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
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. you could maybe use a different DNS Server which has a better API, and potentially even can be used by ACME. Regards Am Fr., 11. Sept. 2020 um 15:09 Uhr schrieb Simon Ser : > 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 > ___ 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
