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

[Erik Nygren <[e-mail]>]

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