On Mon, 12 May 2025, Paul Hoffman wrote: [ speaking only as co-author of draft-ietf-dnsop-domain-verification-techniques ]
Reading this thread and the GitHub issue that spawned it, it is clear that even the co-authors of draft-ietf-dnsop-domain-verification-techniques do not agree on how to handle persistence of validation, much less agreement among WG participants. This may be due to lack of real-world experience with persistent validation, even though we have plenty of experience with single shared secret validation for one instant.
I don't think there was that much disagreement between authors. It was mostly a disagreement between authors and Ben Schwartz about whether the initial DCV record can or should be used as long term permission token. Ben argues the draft is a BCP and should specify the "best way forward" and use two different records. My counter argument is that the draft is a "best CURRENT practice", anod no one I know is currently doing this. For reference, the github thread is here: https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/160
draft-sheth-identifiers-dns is a good start at thinking about the differences between persistent validation and single shared secret validation. It seems safe to limit draft-ietf-dnsop-domain-verification-techniques to just the latter, and hopefully the WG adopts draft-sheth-identifiers-dns and has more discussion about what might become best practices there.
Talking about life cycles is useful, but I think like the lifecycle for SSL certificates, can only be feasibly done if there is an automated system like ACME to fully automate this. The question then though, is how much real "admin permission" does such a record give you if the admin really doesn't know because a certbot like script is running someplace authorizing on their behalf?
I'm posting here because just last week I thought that draft-sheth-identifiers-dns should be part of draft-ietf-dnsop-domain-verification-techniques because there was general agreement on what were best practices. I was wrong, and the more that I thought about what I would say were best practices for persistence validation, the more I realize that I hadn't thought enough about the operational and security considerations. Given that, I propose that draft-ietf-dnsop-domain-verification-techniques be narrowed to only cover the best current practices for shared secret validation, and get that published sooner rather than later. I further propose that draft-sheth-identifiers-dns be adopted by the WG, on the assumption that it starts with the same naming scheme from draft-ietf-dnsop-domain-verification-techniques.
I still believe we are picking the best of _current_ practices, and I still believe the document should document that if you are using the DCV record for continue permission, that it should be clear in the RDATA using key=value pairs with for example expire=never and that DCVs that can be removed after a one time verification, SHOULD contain a expire=<datestamp> value. Punting this discussion further into the future means there will be more DNS littering until that unknown future time. Paul W _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
