I think what would help this situation better is improved off-the-shelf tooling, not standards action with possibly interesting security implications. ------------------------------
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. Ar Iau, 23 Ion 2025 am 00:59 Jared Crawford <jmcrawfor...@gmail.com> ysgrifennodd: > This assumes anycasted DNS, and no anycasted HTTP. How can you be so >> certain in making those assumptions? > > > These assumptions aren’t certain, but they are common enough that popular > ACME clients like certbot > <https://github.com/search?q=repo%3Acertbot%2Fcertbot+propagation&type=code&p=1> > bake propagation delays of tens of seconds into dns plugins by default and > ACME servers give disclaimers > <https://letsencrypt.org/docs/challenge-types/#dns-01-challenge> about it > for dns-01 challenges. Setting up a unicasted HTTP server to answer > challenges can be easily done with off-the-shelf products already deployed > on many commercial web hosting/cloud services. A unicasted DNS responder > serving a stream of challenges at scale is not a common off-the-shelf > product, nor is it a widely provided service. > > This proposal provides an alternative to dns-01 challenges using standard, > off the shelf products in common commercially-available configurations for > situations where http-01 isn’t possible, while still avoiding issues like > DNS credential exposure, propagation delay, DNS providers without APIs, and > bloated TXT records. > > > On Wed, Jan 22, 2025 at 5:06 PM Q Misell <q...@as207960.net> wrote: > >> > In a DNS delegated http-01 flow, clients can immediately validate >> their orders, reducing the time to get their certs from minutes to seconds >> and removing the need to understand and track the particulars of their DNS >> provider’s propagation. >> >> This assumes anycasted DNS, and no anycasted HTTP. How can you be so >> certain in making those assumptions? >> ------------------------------ >> >> Any statements contained in this email are personal to the author and are >> not necessarily the statements of the company unless specifically stated. >> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, >> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company >> registered in Wales under № 12417574 >> <https://find-and-update.company-information.service.gov.uk/company/12417574>, >> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 >> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. >> EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: >> 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru >> maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca >> Digital, is a company registered in Estonia under № 16755226. Estonian VAT >> №: EE102625532. Glauca Digital and the Glauca logo are registered >> trademarks in the UK, under № UK00003718474 and № UK00003718468, >> respectively. >> >> >> Ar Mer, 22 Ion 2025 am 18:27 Jared Crawford <jmcrawfor...@gmail.com> >> ysgrifennodd: >> >>> And even prior to MPIC, no ACME client should be requesting challenge >>>> validation until after it is sure that the record has propagated to all >>>> authoritative nameservers, because there's no guarantee that the single >>>> authoritative perspective would hit the first nameserver to update. >>> >>> >>> This is one of the core problems the draft aims to solve for applicants >>> who cannot use http-01 flows. Tracking global DNS propagation status for >>> orders is a significant challenge. In practice, many clients avoid this by >>> either repeatedly retrying validation or sleeping for a few minutes. In a >>> DNS delegated http-01 flow, clients can immediately validate their orders, >>> reducing the time to get their certs from minutes to seconds and removing >>> the need to understand and track the particulars of their DNS provider’s >>> propagation. >>> >>> This can be solved by CNAMEing to an unreplicated zone specifically for >>> validation purposes or by using a special DNS server designed to serve >>> challenges. In either case, we’re working around most DNS servers’ focus on >>> resiliency/replication rather than change propagation latency. >>> >>> >>> From a CA perspective, http-01 validation is always much slower than >>>> dns-01 validation, because they both require the same number of initial DNS >>>> lookups, but http-01 then requires a subsequent HTTP request, which may >>>> necessitate further DNS lookups if it is 30X redirected. >>> >>> >>> My understanding from this context is that this proposal for delegated >>> http-01 challenges via a CNAME (2 DNS lookups + 1 HTTP request) would be >>> less performant than dns-01 CNAME delegation (2 DNS lookups + 0 HTTP >>> requests) and more performant than a http-01 redirect (2 DNS lookups + 2 >>> HTTP requests). So in addition to the benefits mentioned in the draft, from >>> the CA perspective it could (as a separate validation method and not as a >>> fallback in http-01) also serve as a more performant alternative to http-01 >>> redirect delegation. I’m not sure how meaningful of an optimization this is >>> though, and the fallback vs separate validation method flow is still an >>> open question in the draft. >>> >>> >>> On Tue, Jan 21, 2025 at 6:58 PM Aaron Gable <aa...@letsencrypt.org> >>> wrote: >>> >>>> I'm confused by the claim that MPIC will make DNS validation slower: >>>> dns-01 validation reaches out directly to the authoritative nameservers. >>>> Once the authoritative nameserver has updated its TXT records, all >>>> perspectives should be able to see it at the same time. And even prior to >>>> MPIC, no ACME client should be requesting challenge validation until after >>>> it is sure that the record has propagated to all authoritative nameservers, >>>> because there's no guarantee that the single authoritative perspective >>>> would hit the first nameserver to update. >>>> >>>> From a CA perspective, http-01 validation is always much slower than >>>> dns-01 validation, because they both require the same number of initial DNS >>>> lookups, but http-01 then requires a subsequent HTTP request, which may >>>> necessitate further DNS lookups if it is 30X redirected. >>>> >>>> Aaron >>>> >>>> On Tue, Jan 21, 2025 at 12:21 PM Jared Crawford <jmcrawfor...@gmail.com> >>>> wrote: >>>> >>>>> I think that if the original web server is not involved, then it's not >>>>>> really >>>>>> doing authorization. >>>>> >>>>> >>>>> The original web server for delegated http-01 challenges has the same >>>>> level of involvement as a dns-01 challenge does with a CNAME today. In >>>>> both >>>>> cases, the challenge flow is immediately delegated to an independent >>>>> server. The only difference is that for delegated http-01 the >>>>> authoritative >>>>> source is a web server whereas it’s a DNS server for dns-01. >>>>> >>>>> dns-01 is not really that difficult if you have the amount of control >>>>>> that >>>>>> you'd need for your delegation. >>>>> >>>>> >>>>> >>>>> There are quite a few downsides of the dns-01 flow compared to >>>>> http-01. As an example, http-01 validation can happen in less than a >>>>> second, whereas DNS challenge propagation can take tens of seconds or even >>>>> minutes. And with MPIC, this will be further degraded as propagation delay >>>>> will be slowest out of N (even with a small N=3, this will shift p50 >>>>> propagation delay to be the p80 of single perspective). >>>>> >>>>> On Mon, Jan 20, 2025 at 2:52 PM Michael Richardson < >>>>> mcr+i...@sandelman.ca> wrote: >>>>> >>>>>> >>>>>> Jared Crawford <jmcrawfor...@gmail.com> wrote: >>>>>> > The 301 redirect works only for hostnames with publicly exposed >>>>>> webservers. >>>>>> > All other hosts have to deal with the downsides of dns-01 >>>>>> challenges >>>>>> > compared to the http-01 flow. >>>>>> >>>>>> I think that if the original web server is not involved, then it's >>>>>> not really >>>>>> doing authorization. >>>>>> >>>>>> dns-01 is not really that difficult if you have the amount of control >>>>>> that >>>>>> you'd need for your delegation. >>>>>> >>>>>> -- >>>>>> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT >>>>>> consulting ) >>>>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> Acme mailing list -- acme@ietf.org >>>>> To unsubscribe send an email to acme-le...@ietf.org >>>>> >>>>
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
