Hi Libor, You are absolutely right. The problem is not easily solved.
We will need a way to signal when this is ok and when not. My own security assessment goes like this: If the domain is in transition from one signer to another and a resolver only supports one of the algorithms, the transition is either away from the supported algorithm or to a supported algorithm. So either the old state is insecure or the new state is insecure with regard to this resolver. So signaling to go insecure in case of missing rrsigs doesn’t make the situation worse, but is no improvement either. But the signaling mechanism is an unsolved problem (so far). /Ulrich > thank you for your effort in improving DNS. > > This is a follow-up to your proposal on easing the requirements by RFC4035, > which say, in short, that if there's a DS of an algorithm, there must be a > complete DNSKEY set of that algorithm, and if there is a DNSKEY of an > algorithm, the whole zone must be signed by RRSIGs of that algorithm. > > The counter-proposal is to only require at least one valid DS-DNSKEY-RRSIG > path to sign each RR in the zone. I understand how this would enable > multi-signer setups with the signers supporting different algorithms, which > in turn is beneficial to enable smooth transitions between such signers. > > Let's suppose we go this way. How do we specify the validator behaviour when > there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and the > validator only understands algorithm A, but not B? I guess BOGUS will be no > longer proper here, we would probably stick at INSECURE. Am I correct? > > Now a different scenario. There are algorithm A and B DNSKEYs, the whole zone > is also signed by both alg A and B RRSIGs, and the validator only understands > alg A. Some man-in-the-middle attacker intercepts the answers by fiddling > with the records, while removing algorithm A RRSIGs from the packets. The > validator ends up with INSECURE and lets the attacker poison some cache... > > With current DNSSEC requirements, it is enough for security if there is any > intersection between the algorithms which the zone is signed by, and the > algorithms supported by the validator, respectively. With your proposal, it > would be required that the validator supports all the algorithms, which the > zone is signed by. > > I agree that in case the zone is signed by just one algorithm (occasionally > being rolled-over to just one different one), these conditions are > equivalent. Fortunately, it did not happen yet (or I'm not aware of), that > the existence of different validators with distinct sets of supported > algorithms forced signers to permanently sign zones with two algorithms in > parallel. The question is, if it remains so for the future. I can't imagine > what would happen in case of a "post-quantum apocalypse", maybe it wouldn't > be a problem, but it might. > > It would also cause the paradox and indeed creepy security quirk, that if you > sign your zone with one more algorithm, which is cryptographically strong but > poorly adopted (perhaps experimental), it will result in _less_ security. > Hardly anyone does this, but if they do, they will be surprised, I think. > > Just to be clear, I don't want to fight against your ideas. I'm just pointing > at possible problems that could emerge. > > Thanks, > Libor > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
