Overall, I think that the complexity is not worthwhile. This is a new, validation-specific DNS record that says "are you doing this specific kind of validation? if yes, go look over there".
There's a much simpler option: a new, validation-specific DNS record that says "are you doing validation? good, you're done". Multiple groups have been discussing "static" or "durable" DNS-based validation for a while now. The concept is gaining traction at the CA/BF as we speak. Fundamentally the idea is that all delegation is the same: whether you're delegating to a different DNS zone via a CNAME, or delegating to a different HTTP server via a 301 or your proposed mechanism, the fundamental claim the delegation is making is "whoever controls that over there can issue for this domain". So why not delegate directly to an ACME account? A single, static, durable DNS record (modeled after CAA, but not actually a CAA record, for reasons outlined in rfc8659) that says "this ACME account can issue for this domain" has essentially the same security properties as any of these other forms of delegation. The CA doesn't have to do any further lookups, and the applicant doesn't have to place a random value anywhere. A similar approach works using a DNS record to say "this domain may have certificates issued that contain this public key" (similar to DANE, but only for CAs, not relying parties). So with these static/durable DNS-based methods on the horizon, I'm leery of standardizing something that uses a similar static DNS record but then also still requires additional hoops to be jumped through by both the applicant and the CA. Aaron On Thu, Jan 23, 2025 at 10:32 AM Jared Crawford <jmcrawfor...@gmail.com> wrote: > 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
