> On 2 Mar 2021, at 22:52, Ulrich Wisser <ulr...@wisser.se> wrote: > > @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!
It doesn’t even work then as there the signatures of the non DNSKEY records are of the wrong algorithm. > 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 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
