> > I think what would help this situation better is improved off-the-shelf > tooling, not standards action with possibly interesting security > implications.
Could you elaborate on the specific security concerns with allowing http-01 challenges to be hosted on a dedicated challenge subdomain – something that is already allowed for dns-01 challenges? In order for off-the-shelf tooling to provide comparable benefits (removing all the downsides of dns-01 flows today at no incremental cost), it would need to be a free, purpose built DNS server which focuses on handling validation records that becomes widely adopted by commercial DNS service providers for this purpose. Even if this were a pragmatic alternative, given the high barrier to entry and low payoff, I’d be much more concerned about the security and availability risks of a single or small set of providers handling critical authorization flows across a large number of subscribers. On Thu, Jan 23, 2025 at 8:41 AM Q Misell <q...@as207960.net> wrote: > > 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
