ShivanKaul
commented
1 year ago I left a comment on https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/80/files as well, but thinking about this more, I'm not convinced (though am open to being) that the scope of the privilege being granted needs to be encoded into the record itself. Metadata in the record is mainly for the domain owner's bookkeeping. As long as the Service Provider knows what the scope is of the verifying record, why does it have to be in the DNS record itself? It doesn't affect how a Service Provider queries for the record, and it doesn't affect the size of the DNS response. What is the practical use? I suspect this is why ACME doesn't include it either.
So I think this is worth discussing in some detail in Security Considerations, but not prescribe record metadata for. Thoughts?
moonshiner
(from Erik)
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.