On Mon, May 12, 2025 at 11:43 AM Paul Wouters <p...@nohats.ca> wrote: > > On Mon, 12 May 2025, Ben Schwartz wrote: > > > 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. > > Yes I think this paragraph should be replaced, and we should add a > Section that talks about DVC and periodic revalidations and their > issues in summary, and punt lifecycles of periodic to another document. > > > 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. > > Right. > > > > 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. > > I was talking about the reverse problem. If I "ACME" my period revalidation > records, is it still really a revalidation? It's just a cronjob that I > as IT admin will have forgotten about. I will forget to turn it off when > I am ending a service. > > > 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 am not sure what this means. > > > > 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. > > Perhaps we are talking about different things. Do you mean to say that > you would be okay with 1 DCV to prove control (which expires and gets > removed) and 1 long term record without token/randomness that somehow > points from a unique service name prefix via CNAME or RDATA to the target > service provider's service. And is never updated to prove freshness? > > Or are you after monthly proofs of freshness? > > I think the first is reasonable, as long as you ask for both DNS records > at once, and then tell/show that one of them can be removed after > verification. > > What I don't think is reasonable, is requiring re-authorization by using > a new token every month. It's too complex/annoying/fragily for humans, > and if you automate it away it ceased to perform its intended purpose.
I'm not sure I follow. The point of revalidation is to determine that the authority to control the domain has not been removed. A persistent record doesn't show that, merely that the record remains. Even if the grant of authority is exercised automatically, that grant still exists. What property is gained by requiring humans to be in the loop? > > Paul > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
