Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-verification-techniques-01

[Tim Wicinski <[e-mail]>]

Erik/Shumon/Authors

I left Erik's great comments in
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/50

so we don't lose them.

Thanks Erik ! This is great stuff.  And I forgot I could request early
reviews, which I now have done with SECDIR and ARTART

tim


On Fri, Mar 31, 2023 at 8:52 PM Shumon Huque <[e-mail]> wrote:

> Thanks for the detailed review and suggestions Erik. I'm about to hop on a
> plane home (and I suspect my co-authors are similarly busy). But I just
> wanted to ack your note, and say that we'll review and be in touch
> (probably next week).
>
> Shumon.
>
> On Fri, Mar 31, 2023 at 5:52 AM Erik Nygren <[e-mail]> wrote:
>
>> Hello,
>>
>> Thank you for pulling together this draft!  Having worked on related
>> systems a number of times it will be valuable to have something here
>> standardized.
>>
>> A number of comments and suggestions:
>>
>> 1) APEX domains, and hostnames vs domains
>>
>> You define APEX but don't then reference this.  This is an important
>> topic to cover in considerably more detail, however.  In particular, some
>> systems want to validate an apex domain while others want to validate each
>> particular hostname.  It is critical that validation record and its
>> contents are unambiguous as to which of these is the case.
>>
>> As an example, ACME has separate mechanisms for wildcard certs (eg, "*.
>> example.com") vs individual names (eg, "bar.example.com").
>> This is likely to apply across the board to these systems: sometimes they
>> want to validate usage for a domain and sometimes for just specific names.
>>
>> For the individual hostname case, it is important to clarify that the
>> challenge should be "_foo-challenge.bar.example.com".
>>
>> For the whole domain case this could be  "_
>> foo-wildcard-challenge.example.com"  or have an attribute in the TXT
>> token (eg, wildcard=true).    ACME (rfc8555 section-8.4) doesn't seem to
>> have this differentiation, which seems unfortunate, unless I'm misreading.
>> I'd think that it should be unambiguous to domain admins whether a
>> challenge is for just the "example.com" name, for "*.example.com", or
>> for "example.com, *.example.com, *.*.example,com, etc".
>>
>> What it means to validate a hostname or a domain or a wildcard set of
>> hostnames may vary widely per application, and we may want to talk more
>> about the security considerations here.
>>
>> Ambiguities about whether a given verification token grants powers over a
>> specific hostname or an entire domain also introduce security challenges
>> that we may wish to talk about in Security Considerations.  DNS domain
>> administrators need to be able to understand the consequences of adding in
>> particular challenge entries into their domain, especially in cases like a
>> multi-tenant Enterprise environment.
>>
>> 2) Public suffixes
>>
>> We may wish to encourage (or require) validating against Public Suffix
>> lists (eg, https://publicsuffix.org/), in the absence of a more general
>> DBOUND solution.  At a minimum we should discuss this in security
>> considerations.
>>
>> One Security Consideration is that services operating a public suffix
>> should take extreme care about when they allow underscore labels to be
>> created within a shared domain.  As an example, if a service provider
>> allows "_foo-challenge.publicsuffix.example" to be registered as a domain
>> (for a DNS registrar) or to be created as a CNAME or TXT record (eg, for a
>> dynamic DNS provider or cloud provider) then this might grant unintended
>> powers over all of "publicsuffix.example".
>>
>> We may also want to (encourage? require?) confirming that a user isn't
>> trying to place a validation token on a public suffix.  ACME has this as a
>> "CA Policy Consideration" (Section 10.5 of rfc8555).  There are some
>> legitimate use-cases here, but caution (and perhaps extra validation?) is
>> needed.
>>
>> (For the Appendix, another example would be the PSL itself.  Per
>> https://github.com/publicsuffix/list/wiki/Guidelines
>> It uses "_psl.alphaexample.com TXT
>> https://github.com/publicsuffix/list/pull/100" for validation.)
>>
>> 3) SaaS/Paas/intermediary provider cases (eg, CDNs)
>>
>> A common use-case is for delegation of control over to an intermediate.
>> For example, indicating that a SaaS provider or CDN may manage certificates
>> for "foo.example.com".  One way to handle this is to have CNAME the
>> challenge to that intermediary and then the intermediary returns the TXT
>> record.  For example, you might have:
>>
>> _acme-challenge.foo.example.com. IN CNAME
>> ${TOKENA}.intermediate-provider.example.
>> ${TOKENA}.intermediate-provider.example.  IN TXT  ${TOKENB}
>>
>> This allows .intermediate-provider.example to keep updating TOKENB
>> for each renewal.  (It's not reasonable for the intermediate provider to
>> tell their customer
>> to go back and require updating _acme-challenge.foo.example.com every
>> three months.)
>>
>> This is often going to be done alongside delegating the hostname
>> to the intermediate provider.  For example, there will likely also be a
>> CNAME of:
>>
>>    foo.example.com. IN CNAME foo-example-com.cdn.example.
>>
>> The separate CNAMEs (ie, these being distinct labels) are important
>> because
>> the certificate and validation needs to happen before actually moving the
>> hostname over.
>>
>> This is a case where the CNAME for "_acme-challenge.foo.example.com"
>> generally needs to be persistent
>> for frequent/periodic renewals.
>>
>> Of critical importance is that TOKENA is also secure and has enough
>> entropy
>> and is tied to the particular customer account that provisioned
>> foo.example.com.
>>
>> In the draft we probably want to talk about this as cases where there is
>> a CNAME to the TXT record,
>> and that the target of the CNAME needs to itself always have a token with
>> adequate cryptographic entropy.
>>
>> We might mention in A.1.4 on Time-bound checking that cert renewals are a
>> case where
>> persistence is required, at least of a CNAME to a provider who may be
>> managing the renewals.
>>
>> 3a) Leveraging ACME challenges for other purposes
>>
>> A related question worth considering:  when is it acceptable to leverage
>> ACME challenge for other purposes?  For example, if moving a domain onto a
>> CDN that is going to get a certificate for the domain prior to the
>> migration but which also wants to validate that it is authorized for the
>> domain to be transferred to it, when can the ACME challenge also be
>> leveraged for both purposes?
>> I'm not sure we need to go into this, but perhaps it should be discussed.
>>
>> 4) Multi-provider / multi-CDN setups
>>
>> A related and messier corner-case are multi-provider / multi-CDN setups.
>> For example, "foo.example.com" may CNAME to one of three different CDNs.
>> Each one of these needs to be able to manage a certificate and renew it
>> every three months.
>> This likely applies to some of these other cases as well.  I don't have
>> good answers --- ACME doesn't
>> handle this terribly well today --- but it is worth some thought as to
>> how to handle.
>>
>> 5) Token format / construction
>>
>> It seems like the actual token contents should have more flexibility.
>> I don't think we want a "MUST" on that particular construct.  It may be
>> worth
>> a MUST that there is at least 128 bits of secure entropy, and that the
>> token is
>> either base64 or hex encoded.  But there may be a need to use other
>> constructs in the future (eg, not SHA256).   Giving the current example
>> as a MAY seems reasonable.
>>
>> There may be reasons for other constructs that embed state within the
>> token.
>> For example:  "HMAC-SHA256(private_key, label+account+domain)" may be
>> appropriate in some cases,
>> although has enough security considerations that I'm not sure we want to
>> include that.
>>
>> 6) Binding tokens to requests
>>
>> We should have a note on the critical importance of binding the token to
>> the requesting account and to the requested name.
>> At a minimum this should be in Security Considerations, but it may also
>> wish to be normative.
>> Usage here typically follows a flow of:
>>   a) user/account requests a token for a given $name from a service
>> provider
>>   b) user/account has their DNS admin put their token in for
>> _challenge.$name
>>   c) service validates that _challenge.$name has $token and then grants
>> access to the user/account
>>
>> There are chains of custody here and linkages that need to happen, and
>> are exploitable if they break down.
>> For example, if steps (a) and (c) aren't explicitly linked then a
>> different user on a different account
>> could potentially jump in at step c and grab access.  There may be other
>> corner cases here,
>> and it may be worth some more detailed formal analysis to be able to
>> express what properties are critical
>> for safety.
>>
>> There may be a related Security Consideration that I'm not sure how to
>> handle where a MitM style attack could jump in before step (a).  For
>> example, if the user is phished into talking to a different service
>> provider than they thought they were talking to.  (I'm not sure this needs
>> to be discussed, but is a risk.)
>>
>> 7) TTL recommendations
>>
>> We should provide some TTL recommendations for the TXT record, and
>> perhaps also provide
>> a warning on long SOA (negative caching) TTLs.
>>
>> This seems like a case where we'd want to recommend using short TTLs on
>> the TXT record
>> to allow recovering from misconfigurations.  These shouldn't be polled
>> frequently so cachability
>> is unlikely to be an issue, but if there's a typo and the TTL is long
>> then there may not be a way
>> to recover since the validator may have the bad entry cached for the TTL.
>>
>> A long SOA TTL (ie, negative caching TTL) could also cause issues.
>> Once the service provider issues the challenge the validator may start
>> polling for its presence.
>> The first attempts are likely to get an NXDOMAIN, and if the NXDOMAIN is
>> cached too long
>> this could cause user confusion and/or delay the validation.
>> (I'm not sure it's reasonable to suggest that validators bound the
>> maximum NXDOMAIN caching time?)
>>
>> 8) Policy constraints as a variant
>>
>> Within ACME, challenge tokens exist as only one part of the validation
>> process.
>> They act as an explicit "allow this particular name to be issued this
>> particular cert based on a CSR".
>> There is also another safeguard, however, which is the CAA record.  That
>> acts as a policy-based constraint.
>>
>> As we are generalizing the challenges, it may be worth considering
>> generalizing the policy-based constraints.
>> For example, in an enterprise environment "example.com" may wish to
>> limit the use of _foo-challenge
>> under their domain so that bar.quux.example.com can't put in "_
>> foo-challenge.bar.quux.example.com".
>> (More concretely, example.com may wish to limit the CDNs and/or SaaS
>> providers that can be used
>> within their domain.)
>>
>> This is almost certainly substantial scope creep for this draft, but
>> without it domain admins
>> may be unable to apply policies or manage the sort of risks managed with
>> CAA records.
>>
>> This might be as simple as allowing the definition of _
>> foo-constraint.example.com as a TXT record,
>> with whoever defines _foo-challenge also defining the format of
>> _foo-constraint.
>> As part of validating _foo-challenge.bar.quux.example.com, validators
>> should look for
>> _foo-constraint.example.com and _foo-constraint.quux.example.com and _
>> foo-constraint.bar.quux.example.com
>> and implementing their constraints when present.
>>
>> 9) Registry of labels?
>>
>> I hate to ask it, but is there a need for a registry of _foo-challenge
>> labels?
>> It seems like there could be potential security and operational risks
>> of multiple entities starting to use "_foo-challenge" for unrelated
>> purposes.
>>
>> 10) Security review
>>
>> Given that domain verification is often used as part of security systems,
>> it seems like it would be worth getting some additional security review,
>> such as bringing this to SAAG?
>>
>> Thanks again for working on this much needed draft!
>>
>>       Erik
>>
>> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>