> On 2 Mar 2021, at 13:46, Mark Andrews <ma...@isc.org> wrote: > > >> On 2 Mar 2021, at 23:06, Ulrich Wisser <ulr...@wisser.se> wrote: >> >> >> >>> 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. DNSKEY 257 3 8 xxx >> Example.com. DNSKEY 256 3 8 yyy >> example.com. DNSKEY 256 3 13 zzz >> example.com. RRSIG DNSKEY 8 … >> >> www.example.com. TXT “example” >> www.example.com. RRSIG TXT 13 … >> >> In my eyes there is a clear validation path to the www rr. > > It leads to bogus in a server that *only* support algorithm 8 because THERE > IS NOT AN RRSIG OF WITH ALGORITHM 8
I understand that RRSIGs are missing, but what does “bogus in a server” mean? > >>>> 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 >>> >> > > -- > 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
