Early Review of draft-ietf-dnsop-domain-verification-techniques-05
review-ietf-dnsop-domain-verification-techniques-05-dnsdir-early-reid-2024-07-29-00
| Request | Review of | draft-ietf-dnsop-domain-verification-techniques |
|---|---|---|
| Requested revision | No specific revision (document currently at 06) | |
| Type | Early Review | |
| Team | DNS Directorate (dnsdir) | |
| Deadline | 2024-07-28 | |
| Requested | 2024-07-08 | |
| Requested by | Tim Wicinski | |
| Authors | Shivan Kaul Sahib , Shumon Huque , Paul Wouters , Erik Nygren | |
| I-D last updated | 2024-07-29 | |
| Completed reviews |
Dnsdir Early review of -02
by Jim Reid
(diff)
Secdir Early review of -01 by Benjamin Kaduk (diff) Artart Early review of -01 by Barry Leiba (diff) Dnsdir Early review of -05 by Jim Reid (diff) Artart Early review of -05 by Barry Leiba (diff) Secdir Early review of -05 by Benjamin Kaduk (diff) |
|
| Comments |
This has undergone extensive revision from the earlier versions and we feel it is better reflection of consensus and ready for WGLC |
|
| Assignment | Reviewer | Jim Reid |
| State | Completed | |
| Request | Early review on draft-ietf-dnsop-domain-verification-techniques by DNS Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/dnsdir/aAfAfgUWQx4I4VLwMeYu8bdEQzw | |
| Reviewed revision | 05 (document currently at 06) | |
| Result | Not ready | |
| Completed | 2024-07-29 |
review-ietf-dnsop-domain-verification-techniques-05-dnsdir-early-reid-2024-07-29-00
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.