Re: [Acme] dns-01 challenge limitations
On Sun, Sep 13, 2020 at 5:25 AM Simon Ser wrote: > > 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. It's certainly possible, but to be clear: any option for implementing a validation method needs to be clear enough that browser/OS vendors will permit it as acceptable. The gating function here is whether product vendors, for their products, find it sufficiently secure, not whether CAs do. CAs can often act as intermediaries, proposing ideas to browser/OS vendors. Ultimately, as (sometimes contracted, always delegated) suppliers, acting on behalf of the browser/OS vendor, your ultimate gate isn't demonstrating whether there's consensus to write an I-D, or consensus with a CA, but that there's consensus with the browser/OS vendors that would implement it within their root programs. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
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ß 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 >: > >> > 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
Re: [Acme] dns-01 challenge limitations
Simon Ser 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 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. So, "DNS operators" are not the same thing as "DNS Registrars". Many places do both, and many there is a generation of people who don't know that they are different things. Who think that the only way to manage zones is through a web interface? I think we have an education problem, not a standards problem. DNS AXFR and IXFR has been around for a long long time. RFC3007 is also widely implemented. They are widely used by the majority of DNS operators, at very significant scale. -- 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
Den søn. 13. sep. 2020 kl. 14.10 skrev Philipp Junghannß < teamhydro55...@gmail.com>: > Simon Ser said: > > > > 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. > > > care to share? what other methods are there to prove that you have access > to the DNS zone RIGHT NOW. > dns-01 does not prove that today, because it allows delegation via cname. > > > ___ > 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
Re: [Acme] dns-01 challenge limitations
Simon Ser said: > > 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. care to share? what other methods are there to prove that you have access to the DNS zone RIGHT NOW. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
On 9/13/2020 12:13 PM, Simon Ser wrote: 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. I can't agree more, so what about going after dns-02 challenge instead of trying to fix this ? (And this is up for discussion and as food for thought.) Lets say dns-02 challenge will be little different where the DNS record will hold a public key for specific(or per) domain/subdomain and ACME client will pass the server challenge by using the correspondent private key for that public key to pass the challenge from the server, where server will verify against the DNS published public key, means no DNS access from client side at the time of the challenge itself. This might solve the need for DNS API or even accessing the DNS from the client altogether, this will solve and simplify the challenge while do not compromise the security of the challenge itself and will not compromise the DNS records for the DNS administrators piece in mind, on contrary it will give the ability to control DNS handling on the client side in more secure way, and yet if a client have the ability to change the public key then this will revert to something very similar to dns-01, so in that case ( when it can access and modify the DNS records) client can choose between dns-01 and dns-02, which i don't see need any discussing more that dns-01 itself. Is such challenge viable and secure ? did i missed something obvious with such suggestion ? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
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
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 : > > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi > 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
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
