Hi! Thank you for suggesting these improvements. I'm not sure if it makes sense to add this complexity to the level of domain validation that happens for ACME.
Main reasons I see for this: - A lot of DNS ACL systems have per-zone ACLing, rather than per-label. It's not going to immediately make it easier for someone to gate wildcard issuance. - CAA records are already able to somewhat mitigate part of this problem. - The ACME flow is meant for machines to follow both on the client and server side. The human-readability of the label arguably decreases the security assurances provided by ACME's automated flow. Looking at the `domain-challenge` part of this: https://github.com/enygren/draft-ietf-dnsop-domain-verification-techniques/blob/ec8c2ba87f3129c51347e62ec51073899a404a45/draft-ietf-dnsop-domain-verification-techniques.md#scope-indication-scope-indication. I feel like this introduces another potential security gap. For example, what happens if I do a domain challenge for `com.`, or `co.uk.`. This is a pretty broad level of domain validation that doesn't necessarily follow the hierarchical changes in DNS. While these changes may make sense in human based flows (e.g, validating a domain for a social media network) - I don't think they're the right solution for automated flows. On Sun, Nov 12, 2023 at 8:47 AM Erik Nygren <[email protected]> wrote: > CAA can help, but agreed that it's a blunt tool and only part of the > ecosystem. > > it would be preferable to differentiate within the DV record being added > to the zone, > especially as there could be cases where both an exact cert and a wildcard > cert may > be desirable for a zone. The DNS operator of the zone (or any automation > framework that authorizes access) which is adding the record should > preferably > be able to distinguish what name(s) is/are being validated. Including > this > in the ACME label name would give zone operators better control. > > This would enable CA operators to give better controls to their customers > so would not be in conflict with the MAY in the BR. (Although if we had a > better > ecosystem here it might make sense to tighten the BR at some point.) > In the interim, CAA along with such a differentiation could be used > by zone operators to limit allowed CAs to only those who support this > differentiation feature, which is the scope/intent of CAA. > > Erik > > > > > > On Wed, Oct 4, 2023 at 4:46 AM Seo Suchan <[email protected]> wrote: > >> while it's blunt tool current CAA issuewild record with whiltelist >> accounturi would able to do that, as issuewild overides issue. >> 2023-10-04 오후 4:59에 Q Misell 이(가) 쓴 글: >> >> Regardless of the inclusion of that paragraph in the BR I still think it >> would be worthwhile to be able to limit a DNS based validation to not >> issuing wildcards, should an admin so desire. >> ------------------------------ >> >> 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://e.as207960.net/w4bdyj/Tuxjr0hL>, LEI 875500FXNCJPAPF3PD10. ICO >> register №: ZA782876 <https://e.as207960.net/w4bdyj/w06IBwih>. 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. >> >> >> On Tue, 3 Oct 2023 at 20:04, Seo Suchan <[email protected]> wrote: >> >>> Because CA/B baseline DNS Change auth have this paragraph, I think DNS >>> admin should consider any DNS record there to be valid for wildcard. >>> >>> Note: Once the FQDN has been validated using this method, the CA MAY >>> also issue Certificates for >>> other FQDNs that end with all the Domain Labels of the validated FQDN. >>> This method is suitable >>> for validating Wildcard Domain Names. >>> >>> >>> 2023-10-03 오후 10:31에 Erik Nygren 이(가) 쓴 글: >>> >>> Within draft-ietf-dnsop-domain-verification-techniques >>> <https://e.as207960.net/w4bdyj/KvYIoLDG> there is considerable >>> discussion about the risks associated with DNS DCV records (such as ACME >>> DNS-01) not being clear in the record about whether the scope applies to >>> just a single hostname (example.com >>> <https://e.as207960.net/w4bdyj/qLxR85iE>) or to a wildcard (*. >>> example.com <https://e.as207960.net/w4bdyj/tcl3DZPh>). While DNS-01 >>> has this within the token, the DNS TXT record itself only includes a hash >>> of the token making this hard for a DNS admin to validate. >>> >>> We have a proposed change to use distinct labels for different scopes. >>> For example: >>> >>> * "`_acme-host-challenge.example.com >>> <https://e.as207960.net/w4bdyj/JpqJjdxE>`" applies only to the specific >>> host name of "example.com <https://e.as207960.net/w4bdyj/oHE7qkwz>" and >>> not to anything underneath it. >>> * "`_acme-wildcard-challenge.example.com >>> <https://e.as207960.net/w4bdyj/xVMcJdIL>`" applies to all host names at >>> the level immediately underneath "example.com >>> <https://e.as207960.net/w4bdyj/K9ajyGUJ>". For example, it would apply >>> to "foo.example.com <https://e.as207960.net/w4bdyj/t7IJuCyq>" but not " >>> example.com <https://e.as207960.net/w4bdyj/zyBITmRO>" nor " >>> quux.bar.example.com <https://e.as207960.net/w4bdyj/wvu0juZp>". In the >>> ACME context this would be for *.example.com >>> <https://e.as207960.net/w4bdyj/oirLEOAx>. >>> >>> Pull request for this is here: >>> >>> <http://goog_1991325217> >>> >>> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/90/files >>> <https://e.as207960.net/w4bdyj/awm4ssbi> >>> >>> What is the sense of the ACME WG on if this would make sense? Roll-out >>> would presumably take quite some time so both would need to keep working. >>> >>> I'd suggest that it may make sense to incorporate as part of >>> draft-ietf-acme-dns-account-challenge since the roll-out for both would >>> likely follow a similar pattern. In that case I'd proposed that we'd >>> replace the "-account" in that draft with a specification to use either >>> "-host" or "-wildcard" depending on scope. (That might also mean expanding >>> the title of that draft.) >>> >>> There's also a scope of the domain and its subdomains, covering >>> example.com <https://e.as207960.net/w4bdyj/LVqv0vTq>, *.example.com >>> <https://e.as207960.net/w4bdyj/cV3n3pfP>, *.*.example.com >>> <https://e.as207960.net/w4bdyj/xHJHAQvD>, *.{...}.example.com >>> <https://e.as207960.net/w4bdyj/gnFjNtwj>, etc, but this isn't something >>> specified by ACME due to the semantics of wilcards X509 certs. >>> >>> Erik >>> >>> >>> _______________________________________________ >>> >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> <https://e.as207960.net/w4bdyj/eLTGHv1V> >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> <https://e.as207960.net/w4bdyj/cbz6pd9N> >>> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
