Re: [Acme] Indicating scope in DNS validation label

[Amir Omidi <[e-mail]>]

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
>