# SecDir review of draft-ietf-dnsop-domain-verification-techniques-01 CC @kaduk ## Discuss ## Comments I'm a little nervous about allocating a new BCP number for a topic of fairly narrow scope such as this, but the guidance is good and worth publishing, and I have not better alternative to offer, so I will stifle any objection I might have raised. On the whole the content is reasonable, but read on for some suggestions on how to tighten things up and some questions about why all the pieces are needed. I also made a PR with some editorial suggestions, https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/51 ### Continuing Ownership While I see the example in Appendix A.1.4.1 about Atlassian, when we say in the introduction that sometimes the DNS record must be kept in the zone to prove continued ownership of the domain, that doesn't exactly seem to hold true, or at least only provides a weak indication of continued ownership. I think that to really prove continued ownership the challenge would need to be rotated periodically; just putting one record in once and leaving it there mostly only shows that you had control of the domain at the one point in time it was added and that there isn't anything cleaning up old records. A wholesale migration of the domain to a different DNS server would clean up old records, but staffing changes within a large organization would not. ### Underscore for attrleaf In §3.1 we say "The provider constructs the validation domain name by prepending a provider-relevant prefix followed by "-challenge" to the domain name being validated (e.g. "_foo-challenge.example.com")." which implicitly uses an underscore-prefixed atterleaf name component. Is the underscore part of the required or recommended behavior? ### Hashing the random token The recommendations in §3.1 requires computing the SHA-256 digest of the Random Token before base64url encoding and use as RDATA, but provides no justification for the SHA-256 step that I can see. If the intent is for the Random Token to be a non-public identifier for the challeng with only the digest value being public, we should say that. Otherwise it's not clear what we gain over just using base64url(random-data) as the RDATA. ### TXT RDATA contents We say that the RDATA of the recommended TXT resource record construction must "contain" a certain token construction (rather than "consist of"). Does the format/structure of the RDATA also need to be one that unambiguously identifies where the token is (or is a raw substring match sufficient)? I think we might provide clearer guidance if we laid out the recommended comma-separated key-value format first and talked about the token= contents, and then only afterward mention that even if other formats are used, the RDATA MUST contain the token value (and whether it must be identifiable as such via some metadata). Or we could state up front what properties we want from the RDATA before going on to describe how we achieve those properties. But the current formulation starts out with a MUST-level requirement without much context and then tries to build the context around it, which tends to cause confusion in the reader. Reading again, I think that the core of what is confusing me here is that the SHOULD-level guidance for using the comma-separated key-value pair format is buried as an aside in the mechanism for conveying the instructions for removing a resource record. It seems like it's a more generic recommendation and should be framed as such. ### Instructions for TXT record removal We say > Providers MUST provide clear instructions on when a verifying record > can be removed. The user SHOULD de-provision the resource record > provisioned for a DNS-based domain verification challenge once the > one-time challenge is complete. These instructions SHOULD be encoded > in the RDATA via comma-separated ASCII key-value pairs [RFC1464] > using the key expiry. If this is done, the token should have a key > token. For example: I think that the "these instructions" refers to the "clear instructions" provided by the provider. But the TXT record is something provisioned by the user, not the provider. If the instructions are to be encoded in the RDATA, does that require that the RDATA contents themselves are provided by the provider to the user? I'd strongly recommend including some more description of the workflow that's envisioned if it includes the provider giving the user the entire RDATA contents to copy/paste in place (and also using those RDATA contents as a separate information channel to the user). Additionally, do we make any requirement/recommendation of the format used for the value corresponding to the "expiry" key? ### CNAME chaining In §3.2 we see the text "Another issue with CNAME records is that they must not point to another CNAME" provided, with no reference. But CNAME chains are in heavy use on the internet in practice with no ill effect (case in point: my employer's CDN business), so I'd recommend removing the discussion of CNAME chaining, or supplying a reference and discussion around them that is closer to the deployment reality. ### Relationship to other work While I don't mind a focus on DNS-based domain-verification techniques in this document, it does seem like we might want to spend a little more time placing this work in the context of other schemes. For example, ACME has a number of challenge types, and one of them is essentially the DNS-based stuff covered by this document. Is what RFC 8555 specifies compliant with this document's requirements and recommendations? Do we expect ACME to use our guidance for DNS-based verification and keep doing what they do for HTTP, TLS-SNI, etc. verification? Or should they use a wholistic body of work for all verification such that this document is out of scope for ACME? ### AVOID-FRAGMENTATION reference classification The actual text in Appendix A.1.1 that references [AVOID-FRAGMENTATION] does not contain any usage that would obviously promote it to a normative reference. If there is intent to require implementors of this document to read that one, some additional discussion of which parts are normative requirements and why seems in order. ### Motivation for application-specific name prefix In Appendix A.1.1 we have some good text about an attack where a malicious service can provide to the user the challenge from a different provider, when the TXT verification is on the actual domain name being verified (no prefix/suffix). I would say this fits better in the main document (security considerations, probably) rather than the appendix with survey of current usage. We currently say that the provider and service "should be obvious from the TXT content" in the security considerations but not much about how things go wrong if the provider and service are not obvious. (The existing prose in the appendix is perhaps a little unclear about how the attack actually would get pulled off in practice; it was clear to me based on my prior experience but could be improved by, e.g., naming the parties involved (victim service, malicious service, user, DNS administrator).) ## Nits ### APEX Capitalization I don't remember seeing APEX used as a defined term in all-caps elsewhere. What value do we think we're adding by writing it this way? ### Verifying Record We seem to implicitly introduce the term "verifying record" in §3.1; it might benefit from having an explicit definition. ### Self-referential Appendix Appendix A.1.1 contains the text "See Appendix A for a survey of different implementations.", which is perhaps not a very useful reference. ### DNS name component ordering In Appendix A.1.1 we write "Some providers use a suffix of _PROVIDER_NAME-challenge in the Name field of the TXT record challenge", when that value is a suffix in the wire format of the name but a prefix in the presentation form of the name. This is especially confusing when the next sentence goes on to include an example in presentation form, _acme-challenge., where the _PROVIDER_NAME-challenge is a prefix. Maybe talking about "leaf" rather than prefix or suffix would be most clear.