Put scoping in the record RDATA rather than encoding it into DNS name

[shuque]

See discussion of this issue on the dnsop list: https://mailarchive.ietf.org/arch/msg/dnsop/d3tCliGSa6G_9FwNb6wuYlKMJLA/

Currently, we say:

5.1.2. Scope Indication

For applications that may apply more broadly than to a single host name, the RECOMMENDED approach is to differentiate the application- specific underscore prefix labels to also include the scope (see

scope). In particular:

• "_-host-challenge.example.com" applies only to the specific host name of "example.com" and not to anything underneath it.

• "_-wildcard-challenge.example.com" applies to all host names at the level immediately underneath "example.com". For example, it would apply to "foo.example.com" but not "example.com" nor "quux.bar.example.com"

• "_-domain-challenge.example.com" applies to the entire domain "example.com" as well as its subdomains. For example, it would apply to all of "example.com", "foo.example.com", and "quux.bar.example.com"

New proposal

The rdata supports a "scope=" attribute, that can take on the 3 possible values of host/wildcard/domain. e.g.

_acme-challenge.www.example.org. 300 IN TXT "gfj9XqxxxxxxRg85nM scope=wildcard"

or,

_acme-challenge.www.example.org. 300 IN TXT "gfj9XqxxxxxxRg85nM" "scope=wildcard"

(The 2nd example puts the scope attribute in a separate string in the TXT rdata).

The new proposal allows the verifier to issue a single query to get the info that they need (rather than upto 3).

This also potentially avoids additional security issues related to splicing prefix/suffix substrings into query name labels.

Please review.

Erik - was there a compelling reason that the scope indication should go into the qname label?

@paulwouters @enygren @ShivanKaul

Also tagging @aaomidi

[aaomidi]

I've responded in the mailing list:

There are some benefits in ACME for it being on the label (At least in the ACME use case):

It being on the label provides external confirmation that the ACME server did the correct thing. If it's part of the response, it's a lot easier for an ACME server to falsely claim the scope was something other than what the client had set it to.

The downside of it being up to three lookups doesn't apply to the ACME use case. The specific query that is going to be looked up has been described in the order object (wildcard, subdomain, or just host), so the ACME server will only be looking up one of these.

The main reason we really brought the scoping model to the DNS-ACCOUNT (now SCOPED-DNS-CHALLENGES: https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/) was the verifiability of behavior we get out of it. If we move this out of the qname, then someone can challenge us by saying what do we get out of this that we can't get with CAA.

[shuque]

Thanks for this helpful input! (In theory DNSSEC could prevent falsified responses about scope, but I realize that it's not widely deployed :(

Let's also think about the more general (non-ACME) application use case too. Maybe multiple possible ways to indicate scope are needed.

[shuque]

Assuming we are retaining the current scheme, we should mention some more details about why ACME (and ACME like use cases) do not require multiple DNS queries to obtain the validation record answer.

[aaomidi]

Thanks for this helpful input! (In theory DNSSEC could prevent falsified responses about scope, but I realize that it's not widely deployed :(

Yeah and it becomes harder as the client side to really validate dnssec was used :(

Let's also think about the more general (non-ACME) application use case too. Maybe multiple possible ways to indicate scope are needed.

To be fair, I think the label provides stronger guarantees on the delegation of domain authorization in general. ACLs can be suited for editing the resource under a qname, but not editing the qname itself for example.

[aaomidi]

Assuming we are retaining the current scheme, we should mention some more details about why ACME (and ACME like use cases) do not require multiple DNS queries to obtain the validation record answer.

Where would you like to talk more about this? In this draft or somewhere else?

[shuque]

Assuming we are retaining the current scheme, we should mention some more details about why ACME (and ACME like use cases) do not require multiple DNS queries to obtain the validation record answer.

Where would you like to talk more about this? In this draft or somewhere else?

I'd like to at least mention somewhere in our draft how consuming applications avoid multiple queries for the scoped validation records (e.g. because they know in the ACME use case which scoped record needs to be queried). If that is clear in your scoped challenges doc, we could have a reference to that.

[shuque]

Closing this issue for now, as we've covered it in this PR https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/108