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.
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
