> On 2 Mar 2021, at 12:55, Mark Andrews <ma...@isc.org> wrote: > > > >> 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.
Why would the signatures of the non DNSKEY RRset need to be of the same algorithm as the KSK? Lax-validation says that “any validation path” should be accepted. example.com. DS 123 8 2 xxx example.com <http://example.com/>. DNSKEY 257 3 8 xxx Example.com. DNSKEY 256 3 8 yyy example.com <http://example.com/>. DNSKEY 256 3 13 zzz example.com <http://example.com/>. RRSIG DNSKEY 8 … www.example.com <http://www.example.com/>. TXT “example” www.example.com. RRSIG TXT 13 … In my eyes there is a clear validation path to the www rr. > >> 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
