Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt

[John Levine <[e-mail]>]

It appears that Shivan Kaul Sahib  <[e-mail]> said:
>-=-=-=-=-=-
>
>Hi folks, we (finally) published a new version of the domain verification
>techniques draft, now as intended-BCP. We've had some feedback from
>providers but would love for folks to review, especially people who would
>actually use it.

While I think it would be good to publish some best practices in this area,
this draft still seems scattered and makes some assertions that seem to me
to be somewhere between unsupported and mistaken.

I think we agree that the goal is there are two parties, call them
owner and verifier, and the verifier gives the owner a random token
that the owner puts in its DNS to show it owns the domain.  There are
a bunch of different aspects that one can look at independently.

One is where the token goes, in the name or contents of the owner's
record. I think we agree that putting the token at the owner's host
name is a bad idea, but either of these can work, with a1b2c3 being
the random token:

_a1b2c3.example.com IN ... "whatever"
_crudco.example.com IN ... "a1b2c3"

If you use a fixed prefix, _crudco in this case, you should register it
in the RFC8552 attrleaf registry.

Another is what record type to use. I find the arguments against CNAME
unpersuasive, basically saying that if you do something dumb, it won't
work, which is true, but it's always true. I realize that RFC1034 says
not to chain CNAMEs, but we all know that people chain CNAMEs and it
works, e.g. www.microsoft.com goes through three CNAMEs and it works
fine. If you use a _name in the attrleaf registry or a _random prefix
I would think the changes of a CNAME colliding with something else are
low, and a verifier presumably controls its own DNS and can keep CNAME
chains short.

So any of these could work:

_a1b2c3.example.com IN TXT "crudco"
_a1b2c3.example.com IN CNAME verify.crudco.wtf.
_crudco.example.com IN TXT "a1b2c3"
_crudco.example.com IN CNAME _a1b2c3.crudco.wtf.

As you sort of note in one of the appendices, you can have different
tokens in the name and the content if for some reason that is useful.

For the length of time the token is valid, there seem to be only two:
five minutes for a one-off verification like for ACME, or forever for
someone who is doing continuing analysis of something in your domain,
typically web analytics. While I can see aesthetic reasons to get rid
of expired one-off tokens, I don't see the point of putting an
expiration time in them, nor any particular harm in leaving them there
if they are at _name and not the main host name. You might also say
something about TTLs, e.g., not to have a 12 hour TTL for a token you
plan to remove in a few minutes.

There are some other minor points. You say to generate 128 random
bits, but then to hash them to 256 which I don't understand. (As RFC
4086 sec 6.2 notes, strong random bits often are already hash output.)
If 128 bits is enough, use 128 bits, if you need 256, generate 256.
Either way I'd do base32 rather than base64 encoding to make the
result more robust against helpful software that does you a favor by
case folding.

Overall, I'd lay out the options, and point out the advantages or
disadvantages of each rather than just saying "do this" without a
strong basis not to do it the other ways that work fine in practice.

R's,
John