Mark, I totally agree with you. And I didn’t propose a change to the specs or anything. I just promoted to continue with lax-validation, because it helps with some operational problems.
> On 2 Mar 2021, at 20:46, Mark Andrews <ma...@isc.org> wrote: > > > >> 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
