Paul W wrote: > 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.
I believe the current draft text in the datatracker agrees with me. For example, draft-07 Section 4.3 says > Some Application Service Providers currently require the Validation Record to > remain in the zone indefinitely for periodic revalidation purposes. This > practice should be discouraged. 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. Surely something cannot be a "best current practice" if it is also "discouraged" and one "needs" to use the other approach. However, other portions of the draft are somewhat in tension with this paragraph, hence my PR to try to clarify the draft's stance. > 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? The (unstated!) presumption of DCV is that an actor who can write a DCV record at _$foo-challenge.$domain can also overwrite any record on $domain. This actor could already do a lot of bad things, like taking websites on $domain offline, so their permission is sufficient to perform certain actions that pose risk (e.g. creating a risk of DoS), as that risk is not incremental. Without this assumption (or an equivalent rule about parties authorized to update parts of the zone), DCV doesn't work at all. Perhaps we need to make that more explicit... > I still believe we are picking the best of _current_ practices ... Drawing a very hard distinction between DCV and persistent authorization is certainly a current practice, and in my view (and the view of draft-07!) it is the best one. Not all current practices are best ... even if they are indeed widely used without incident. --Ben ________________________________ From: Erik Nygren <[email protected]> Sent: Monday, May 12, 2025 12:52 PM To: Paul Wouters <[email protected]> Cc: Paul Hoffman <[email protected]>; dnsop WG <[email protected]> Subject: [DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques) I agree with Paul W here. I don't think there's disagreement between the authors, and I believe that it is important to cover\ the current practices where assumptions about persistence are being made. If we go back to the examples that I agree with Paul W here. I don't think there's disagreement between the authors, and I believe that it is important to cover\ the current practices where assumptions about persistence are being made. If we go back to the examples that were in an appendix of earlier versions of this draft some of them do assume persistence, and that is part of how we got into this. As such, I do think we have experience there with some of the pitfalls of certain implementations around persistence. (For that matter, an NS record is a form of persistent delegation, although outside the scope of this draft.) Since this doesn't appear to be clear to some readers it does seem like it would be worthwhile to add some text to explain point-in-time-validation vs persistent validation and to highlight pitfalls. I don't really think there is as clear of a distinction between point-in-time validation, persistent validation, and delegation for ongoing point-in-time validations as Ben implies. They are all cases which apply and are variations and it would be good to cover all of them in the draft as the current version does. Erik On Mon, May 12, 2025 at 12:41 PM Paul Wouters <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
