On Sat, Mar 8, 2025 at 7:01 AM Paul Hoffman <paul.hoff...@icann.org> wrote: > Big thanks to the authors of > draft-ietf-dnsop-domain-verification-techniques for the massive update > in -07 to make it easier to follow. The document remains very > important to help applications understand that domain control > validation should not be "stuff TXT into the zone apex".
Thanks. > Having said that, I would still like to see a major revision > throughout the document to take it away from 2119-level SHOULDs and > MUSTS for things that really should instead be "if your use case is > $x, you should consider doing $y". The current wording makes it hard > to implement some use cases, while later saying that those use cases > are in fact valid. Can you elaborate on what specific use cases have been made hard to implement by the current text? The only such use cases I'm aware of are applications that want to use something in the DNS to perpetually assert some relationship with the domain. Our draft states that for domain control validation purposes, there should be only time limited challenge tokens that should not be reused for domain control re-validation actions at a future time, for reasons we explain in the draft. I think those use cases are valid, but are a bit different from nonce based DCV, and also require some additional attention to domain lifecycle management issues. Swapneel Sheth (Verisign) and I have already been talking about this topic this weekend in Bangkok, and I understand that he is working on another draft to address some of this. My proposal would be to add a caveat to the relevant section of the DCV doc, and work with Swapneel to make sure the drafts are not in conflict with each other, which should not be hard to do. > It makes demands in many places that are only best > practices for a subset of the intended readers, and that do not affect > interoperability. Again, can you elaborate? Having said that, I do feel that some of the statements in the draft are perhaps too strong and could be toned down. I'm fine with changing many of the MUSTs to SHOULDs, as that would make the draft less antagonistic to application providers that have not (yet) adopted these recommendations. > My preference is that there are just two SHOULDs, both in the > introduction: SHOULD NOT pollute the zone apex with TXT records, and > SHOULD instead use underscore labels as described in the rest of the > document. The doc uses the term RECOMMENDED for the underscore label (which is like SHOULD). It does not distinguish the zone apex, as this applies generally to any part of a zone. Application providers may want to validate control of the domain "finance.example.com" say, which may not be a zone but a subdomain within the zone example.com, and could cause the same cluttering there. > After that, couch every suggestion with reasoning, talk > about how different use cases might cause you to do different things, > and give more examples. Specific use cases that may require persistent identifier records will be described and tackled in Swapneel's draft. Apart from that, I don't know of any cases that cannot be accommodated by the recommendations in this draft. If you have any mind, please describe them, and we can discuss. > Many of the current SHOULDs and MUSTs are based on the use case of a > certificate authority using ACME. That's a good use case, good enough > where it should have its own section near the end (mentioned in the > introduction) specifying how each of the options from throughout the > document apply to that use case. I don't think that's true. There isn't anything in the draft that is specific to the certificate authority/ACME use case. The one part that arguably was the "scope of indication" mechanism, which was taken out in -07, and is planned to be taken to ACME as a separate draft. I look forward to hearing comments from my co-authors on this topic, and others in the working group. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
