Hi Ulrich,
please see below..
Libor
Dne 24. 02. 21 v 16:01 Ulrich Wisser napsal(a):
On 23 Feb 2021, at 17:49, Ben Schwartz
<bemasc=40google....@dmarc.ietf.org
<mailto:bemasc=40google....@dmarc.ietf.org>> wrote:
On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler <wei...@watson.org
<mailto:wei...@watson.org>> wrote:
...
Recognizing that I'm likely biased by my history of working on the
current "mandatory algorithm rules", I don't buy the need for this
complexity. In practice our "weak" algorithms aren't _that_ weak.
And, if they are, we might as well stop signing with them entirely.
I think that was true for a long time, but I'm not sure it's still
true, or will stay true. I'm particularly motivated by the ongoing
discussion about adding Algorithms to the registry [1], and a recent
overview of Post-Quantum cryptography for DNSSEC [2]. Also, 829-bit
RSA was factored last year [3]. Validator update timelines are Very
Slow, so we should be thinking about adding features we might need
before we need them.
Even if we are currently in a state where zone owners feel like they
have simple, safe choices, I don't think we should assume that this
will remain true indefinitely.
This seems like unnecessary further loading of the camel.
FWIW, my preference would be to simply remove the lax-validation rule
from RFC 6840, which would simplify the standard overall ... but
there must have been a good reason for it. Strict Mode might be a
stepping-stone in that direction.
Not only am I in favor of the RFC6840 lax validation, it is in fact
necessary for secure DNSSEC operation.
I think lax validation is not necessary for secure DNSSEC operation.
DNSSEC can be operated securely in the strict mode completely, including
algorithm roll-overs.
In fact I believe the RFC 4035 needs to be updated to explicitly allow
algorithms without signatures.
I believe the lax validation needs to be denied completely in order to
not support RFC4035 (and 6840) non-compliant signers.
At the current state of dnssec RFC definitions it is unclear how you
could change DNS operators securely if these operators do not sign the
zone with the same algorithm.
IMHO it's pretty clear: it's simply not possible at all.
Ben, if you decide to persist with this idea, I've filed some issues
in your GH repo.
Thanks!
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00>
[2] https://indico.dns-oarc.net/event/37/contributions/811/
<https://indico.dns-oarc.net/event/37/contributions/811/>
[3] https://en.wikipedia.org/wiki/RSA_numbers#RSA-250
<https://en.wikipedia.org/wiki/RSA_numbers#RSA-250>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
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
