[DNSOP] Dnsdir early review of draft-ietf-dnsop-domain-verification-techniques-05

[Jim Reid via Datatracker <[e-mail]>]

Reviewer: Jim Reid
Review result: Not Ready

I am disappointed that many of my earlier review comments have not
been addressed and the authors have not explained why.

doc says "Other techniques such as email or HTTP(S) based validation are out-of-scope." Why?

acme seems to be a better solution. ID needs to explain why it's unsuitable.

don't like "domain owner" throughout the doc, even if it is imported from RFC9499

CNAMEs can exist with DNSSEC rrtypes

"issuance" is icky to a native English speaker

4. Perhaps wait for completion of ACME-SCOPED-CHALLENGE work?

5.1 Discourage CNAME chaining: it's ugly and unreliable

5.1 why 128 bits? Why not 129?

5.1 base32, base16 or hex16. Pick one. Pretty please.

5.1 _<PROVIDER_RELEVANT_NAME>-challenge could be too long for a label
    is -challenge necessary? ditto -wildcard, -host -domain
    Maybe use subdomains of PROVIDER_RELEVANT_NAME? ie:
    _host-challenge.<PROVIDER_RELEVANT_NAME>.whatever

5.2.2 Why bother with CNAMEs at all?

5.3.1 Why key-value pairs instead of JSON, CBOR, etc?

5.3.2 Make it clearer this isn't TTL or SOA expiry values

5.4 SHOULD or MUST remove?

5.5 "identifier token should be stable over time" - vague!
    what's meant by "stable" and "over time"?

5.5 not clear how/why 5.4 and 5.5 differ in substance

5.6 exact and full (FQDN?) for what? - just say complete?

5.7 APIs MAY be used - current text seems too vendor-specific

5.8 "caching or resolver load will not be an issue"
    [citation needed!] This claim is a subjective opinion.

5.9 why not use a dedicated RRtype?

5.9 CNAME love seems vendor-specific

5.10 does anyone use DNAME?

6 Why just use (insecure?) email for OOB communication?
  Incomplete threat model: spoofing, replay attacks, bad expiry info, etc

disallowing "_foo-challenge.co.uk" is unreasonable and wrong
can't have special sauce which lets some domain names work but not others

public suffix list isn't standardised or in an IANA registry
       unsuitable for an RFC?

Documenting current behaviour/practice in Appendix A seems unwise for
an RFC. It'll inevitably become overtaken by events.

An appendix with illustrative examples would be nice.