On Tue, 6 May 2025, Ben Schwartz wrote:
____________________________________________________________________________________________________________________________________________________________________
From: Erik Nygren <[email protected]>
> 1) Is DCV just point-in-time validation of control or does the continued
presence of a DCV record an ongoing assertion of validation intent?
Ultimately, deployments can do whatever they want here. The question is, what is the BCP
for the meaning of an "old" DCV record, since it clearly means something
very different from a "fresh" record.
I think the answer is "nothing". Otherwise, we are proposing to mix two
different meanings into this record, making it much harder to say what DCV is.
Older versions of the draft had a human readable expiry time on the
record to help with this exact problem, but people thought it was
too complicated. It might still be the bets way forward to
introduce something like that. Or at least say, if you are mixing
these two types of records, clearly indicate this in the RDATA.
Section 4.1.2 describes how to add token meta data. Perhaps we
can make this more explicit?
> 2) How does Delegated DCV fit in here, where by definition of the use-case
its continued presence is an ongoing assertion of validation intent to allow an
intermediary to perform recurring but more time-limited revalidations?
I believed a Delegated DCV CNAME means "I authorize this other domain to perform DCV
on my behalf". It is a persistent authorization, not a proof of control.
> 4) How do we balance some conflicting considerations?
> 4a) For persistent records, allowing the domain owner to know when they are
safe to remove (and when they are still being relied on)?
Make their purpose evident from their contents. Who is authorizing whom to do
what?
See above.
> 4b) How do make persistent records safe to be persistent (eg, not derived
from any secret that needs rotation)?
> 4c) How do we avoid putting sensitive information (or anything derived from
sensitive information) into the DNS, such as account names or account identifiers?
I think these identifiers can reasonably be "obfuscated" where necessary without
issue. The important thing is that they be clearly distinguishable from "ephemeral
DCV" records, ideally with a different format reflecting their distinct purpose.
Same here, see above.
...
> Using high-entropy tokens (as in the current draft) with no confidentiality
requirements or semantic meaning seems like the safest approach for cases where the
continued presence of a DCV record is an ongoing assertion of validation intent.
Note that CAA records could easily have been implemented in this way, resulting in
improved "confidentiality" by not revealing which CAs are approved. Instead,
the
ACME group decided to make them human-readable. I think this was a wise
decision that would also be appropriate in many other contexts (though perhaps
not all).
In their case, the information is already revealed in the current
certificate, which also shows which CA is in use. Obfuscating
vendors, while still allowing a DNS admin to recognise who the
record belongs too and whether it is safe to remove are conflicting
properties.
...
> As part of this we would *NOT* specify that DCV is only a point-in-time
protocol, but to clarify what is needed for it to safely be used as a persistent
validation (which is something that the ecosystem is likely relying on, as
re-validation doesn't scale in all cases and will just regrade to validation not
happening).
Persistent validation of what? Old DCV records don't prove control of the
domain. They might prove something else though...
I don't think we can get DNS admins to go through all their DCV records
each month to manually update them to indicate continued service
consumption. The reality is that DCVs are re-used as continued
endorsement records. I don't think the draft should try and force
users into monthly manual actions - it will simply be ignored.
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
