Thanks, Shivan, for addressing my comments. Barry
On Mon, Jul 10, 2023 at 12:04 PM Shivan Kaul Sahib <shivankaulsa...@gmail.com> wrote: > > Hi Barry, we've uploaded a new version that should address your helpful > comments: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ > > On Mon, 3 Apr 2023 at 00:38, Barry Leiba via Datatracker <nore...@ietf.org> > wrote: >> >> Reviewer: Barry Leiba >> Review result: Ready with Nits >> >> This is short and reasonably sweet, easily digested. I have a few minor >> comments that I think will help make the document slightly clearer, and I >> hope >> you'll consider them: >> >> — Section 3.1 — >> >> I think this is generally understandable, but reuse of “it” does allow room >> for >> error. I suggest avoiding vagueness, possible ambiguity, and >> misunderstanding >> as follows: >> >> OLD >> 1. Generate a Random Token with at least 128 bits of entropy. >> >> 2. Take the SHA-256 digest output [SHA256] of it. >> >> 3. base64url encode it. >> >> NEW >> 1. Generate a Random Token with at least 128 bits of entropy. >> >> 2. Create a SHA-256 digest [SHA256] of the Random Token. >> >> 3. base64url encode the SHA-256 digest. >> >> END >> >> (And you might include RFC 4648 as a reference for base64url encoding.) >> >> One thing that I do find unclear is this: >> >> 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: >> >> _foo-challenge.example.com. IN TXT >> "token=3419...3d206c4,expiry=2023-02-08T02:03:19+00:00" >> >> First: It’s unclear how a one-time challenge fits in with an “expiry” key. >> Is >> it meant to be the case that lack of an “expiry” key means that the “token” >> is >> meant for one-time use, and presence of “expiry” makes it time-based? Or >> something else? I think this could be clearer. >> >> Second: “the token should have a key token” confused me until I finally >> realized that you ought to be using quotes to identify the key names, thus: >> >> NEW >> 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”. >> END >> >> That makes it clearer that the key names are not just words in the >> explanatory >> text. >> >> — Section 3.2 — >> >> In the newspaper business, what you’ve done here is called “burying the >> lede”. >> I suggest instead, leading with the recommendation and following with the >> reasoning: >> >> NEW >> Because CNAME records cannot co-exist with any other data, it is >> NOT RECOMMENDED to use CNAMEs for DNS domain verification. >> >> Reasoning: What happens when both a CNAME and other records exist >> depends on the DNS implementation, and might break in unexpected >> ways. If a CNAME is added for continuous authorization, and for >> another service a TXT record is added, the TXT record might work but >> the CNAME record might break. Another issue with CNAME records is >> that they must not point to another CNAME. But while this might be >> true in an initial deployment, if the target that the CNAME points to >> is changed from a non-CNAME record to a CNAME record, some DNS >> software might no longer resolve this as expected. However, when >> using a properly named prefix, existing CNAME records should never >> conflict with regular CNAME records. >> END >> >> Thanks, >> Barry >> >> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
