> On 3 Mar 2021, at 04:44, Ulrich Wisser <ulr...@wisser.se> wrote: > > I don’t think the dnssec specification say that a rr set has to be signed > with an algorithm that is specified in the ds rr set.
It does with formal MUSTs. > The spec requires rrsigs of each algorithm to be present at the > authoritative. But there is no requirement on the validation to stay with one > algorithm. No there isn’t but when you only support one algorithm in the validator, if the signers fail to meet the MUST then validation fails. The MUST on the authoritative side is there to prevent failures in the validator. > What I want to accomplish is that two name server operators can move a domain > between them even when they use different algorithms. With lax-validation > this is possible, at least when the validator supports both algorithms. But it doesn’t work when it doesn’t. This part of DNSSEC was carefully designed this way. > This move would of course make the authoritatives not rfc compliant for some > time. > Both authoritative would have to have a ZSK in their dnskey set that uses an > algorithm for which they do not serve rrsigs. > I believe this to be a lesser problem than switching dnssec off. So you agree with me. There is no way to transfer signing between operators and perform an algorithm change at the same time if the operators refuse (or can’t because it is not supported by the software) to sign the zone with the algorithm the other operator is using. When I use the term “work” that means that answers validates for *every* validator that is correctly following the protocol. That was the design goal from the very beginning. > /Ulrich > > > >> On 2 Mar 2021, at 18:25, Brian Dickson <brian.peter.dick...@gmail.com> wrote: >> >> >> >> On Tue, Mar 2, 2021 at 4:47 AM 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 >> >> Rather than argue about this example (which may be incomplete and/or >> erroneous), let's try to "fix" the example, and clarify which algorithm is >> new, and which algorithm is old, including what is on each of the two >> servers in terms signatures and keys? >> >> (Clearly this cannot be valid to be on one server, given the DS and >> RRSIG(TXT) are not the same algorithm). >> >> I think the requirement for considering the addition, is the inclusion of >> both ZSKs in both instances of the zone, AND the publication of both DS >> records in the parent. >> >> If this happens well in advance of the change of NS record in the parent, >> what else needs to happen? >> And how is this handled by validators that handle algorithm 8 but not >> algorithm 13? >> >> If the example is expanded and corrected, I believe the answer should be, >> the algorithm 13 only zone is either insecure, or bogus, depending on the >> absence or presence of the algorithm 8 DS. >> >> I don't see a clean way to avoid a race condition between the NS records in >> the parent, and the DS records in the parent, given caching. >> >> This is likely why Joe Abley was suggesting going insecure for a brief >> period is the only way to avoid anyone getting "bogus" as a validation state. >> >> Algorithm 8 would go insecure permanently, while Algorithm 13 would go >> insecure for a brief period then go secure again. >> >> Perhaps the brief bogus for Algorithm 8 is acceptable, in which case the >> decision is really one to be made by the zone owner. >> >> Brian > -- 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
