Thanks for the in-depth reply! I think we are in agreement on many topics. On Mar 15, 2025, at 17:55, Shumon Huque <shu...@gmail.com> wrote:
> 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? Throughout the draft, including in the introduction, there is a strong emphasis on "time-bound" for the domain control validation. This excludes the many current and future use cases that are not time-bound, but instead use domain control validation for long-term association. Those use cases have lower security properties than those emphasized in the draft. Another set of use cases are those that do the association via public keys or hashes of public keys instead of random tokens. The emphasis on random tokens throughout the document excludes these use cases. Another set of use cases are those where the user is expected to type the token (instead of copying-and-pasting). If the token is generated by the application service provider and told to the user in the service's GUI, having a typeable but less random token works for the use case but is prohibited by the draft. There are others, but I think this gives a good overview. > 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 strongly disagree that the draft explains that. The one part of the draft that covers this is: Subsequent validation actions using an already disclosed token are no guarantee that the original owner is still in control of the domain, and a new challenge needs to be issued. That is not an explanation, it is saying that some security models don't meet the standards of the document author. There are plenty of times when a continued existence of a well-known record is sufficient for the application service provider. > 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. Fully agree. > 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. Having a companion draft that covers lifecycle issues is good, but that doesn't mean that the main WG draft should prohibit use cases unnecessarily. > > 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? For example, requiring strong random nonces instead typeable nonces, public keys, and so on. Another example is saying that the token must be the first part of the string in the record: the application service provider obviously knows how to parse their own text values. There are many others. > 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. Why even "SHOULD" if it doesn't help interoperability? > > 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. Good point! The recommendation in the introduction should be "SHOULD NOT pollute the zone with TXT records except in the underscore labels". > > 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. Why not make them valid here? The current document cannot justify the records being "time-bound" because they really are "event-bound", namely when the application service provider does the lookup and finds the expected record. After than, the presence of the record is not relevant to the even-bound use cases and is perfectly fine for the persistent use cases. > 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. See above. > > 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. This confuses me. TLS certificate issuance is talked about throughout the document, starting with the second sentence of the introduction. > I look forward to hearing comments from my co-authors on this topic, and > others in the working group. Me too! --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
