________________________________ From: Paul Wouters <[email protected]>
> ... 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. I agree. I put a section like that at the top of my PR [1]. We can certainly expand it if you think we need more text. >> 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. To be concrete: suppose an untrusted party shows up and says "Hey can I add a new TXT record to your zone? It's not at any name you're using.". Without DCV, this is potentially safe. This party can't influence the behavior of the names you care about. With DCV, this is totally unsafe. So DCV introduces a (arguably) new assumption about DNS zone behaviors. This is mostly hypothetical ... except for any public suffixes that aren't blocking all underscore-prefix names. > 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? That's precisely what my PR recommends. > Or are you after monthly proofs of freshness? Only if the verifier really needs repeated DCV for some reason. If the verifier just wants to confirm authorization, don't use DCV for that. Really, I would like to go even deeper and ask: are we sure all these deployments actually want DCV semantics? Maybe they should be using persistent authorization instead, but are copying the DCV pattern from other deployments. --Ben [1] https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/160/files
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
