On the other hand, do you know any zones that permanently (other than
active roll-over) sign with two algorithms in parallel? AFAIK this is
_not_ the usual way how new algorithms are being rolled out. I guess new
algorithms would continue to be adopted in the same way: first wide
enough support in validators, second adoption (exclusive) by some
pioneering zones who "risk" being insecure for older validators, third
general adoption. I don't think it would be so huge an issue, but still
a bit of an issue, as I described in the first e-mail.
Libor
Dne 21. 03. 22 v 10:32 Ben Schwartz napsal(a):
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
