I'm concerned about this. Concretely, this seems like it would raise a major barrier to rolling out new algorithms. For example, any zone that offers ECDSA and RSA signatures would be insecure for any RSA-only resolvers. It's hard to see how new algorithms could be adopted at scale if this rule were in place.
On Sun, Mar 20, 2022 at 4:42 PM libor.peltan <libor.peltan= 40nic...@dmarc.ietf.org> wrote: > Hi Ulrich, dnsop, > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
