Re: [Acme] Indicating scope in DNS validation label

[Erik Nygren <[e-mail]>]

The ability to have differentiated ACLs is actually a big reason to have
the labels differentiated.  It is possible to have per-label ACLs and some
systems do support it.  With having a single label for both wildcard and
exact it isn't possible to differentiate in an ACL between the wildcard
permissions and the exact permissions.  With distinct labels it does become
possible to differentiate in the ACL for an automated flow.

Hopefully most domain validation is either automated flows, or adding a
CNAME to a system that provides automation.  That latter case is another
one where being able to have differentiation would help (ie, to know
whether that CNAME allows for wildcards or just exact name issuance).

        Erik


On Mon, Nov 27, 2023 at 3:02 PM Amir Omidi <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme <https://e.as207960.net/w4bdyj/eLTGHv1V>
>>>>
>>>> _______________________________________________
>>>> Acme mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>> <https://e.as207960.net/w4bdyj/cbz6pd9N>
>>>>
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>