@Håvard No, that isn’t sufficient. A resolver could have the old DNSKEY set in cache but get signatures from the new servers. This can be solved by cross signing the ZSK -> put the ZSK of the other provider in the respective DNSKEY set, no need to exchange private keys, only the DNSKEY records. Then you will always have a validation path.
@Mark, that is exactly what I am talking about, a forced algorithm change can only work, when both operators cooperate and if we insist on lax-validation. We need both! Cooperation is of course another problem.There is no incentive for the “losing” operator to cooperate. And because today moving a secure domain is a complex manual task, no-one is interested in helping out. We could make this much easier with the right support in protocol and software. Shumon and I will talk on this next week. /Ulrich > On 1 Mar 2021, at 20:58, Mark Andrews <ma...@isc.org> wrote: > > Throw a forced algorithm change in on top where neither provider is willing > to sign with the other providers algorithm. > > -- > Mark Andrews > >> On 2 Mar 2021, at 06:55, Havard Eidnes <he=40uninett...@dmarc.ietf.org> >> wrote: >> >> >>> >>> - Switching providers while staying secure requires >>> inter-provider cooperation, including publishing ZSKs from >>> both providers in the DNSKEY RRSET served by both providers. >> >> What? >> >> Maybe I just don't understand the context or conditions here, but >> ... >> >> Isn't it possible to stand up a new signing and publishing setup >> with new ZSKs and new KSKs, and have both the old DS record >> pointing to the old setup's KSK and a new DS record pointing to >> the KSK of the new setup registered in the parent zone, and then >> change the actual delegation (NS records), while still retaining >> both the two DS records for a while until the data from the old >> setup has timed out? >> >> There is then no need to share the secret part of the KSKs or the >> ZSKs between the old and the new providers, or to include both >> the new and the old ZSKs in the zone. >> >> Regards, >> >> - Håvard >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
