> 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 >>> 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
