Hi Evan On Tue, Mar 28, 2017 at 02:41:27AM +0000, Evan Hunt wrote: > On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote: > > also, a validator that outputs "secure" based on MD5 inputs is making a > > promise it can't keep. > > MD5 is known to be breakable, but it's not *as* breakable that hasn't been > signed, or a resolver that hasn't turned on validation. A validator that > doens't implement an algorithm treats any domain signed by that algorithm > as if it were not signed at all. A MITM attack on that domain goes from > "not as difficult as we'd like" to "trivially easy". I don't see this as > a net improvement to security.
It doesn't seem the same as a validator not supporting any algorithms.
Consider a zone that its operator has signed with RSASHA256 (for current
generation resolver implementations) and RSAMD5 (for implementations
that predate RSASHA256).
In the case where a resolver implementation supports RSASHA256 and
doesn't support RSAMD5, if the trust chain using RSASHA256 is broken,
validation would fail as RSASHA256 is a supported algorithm.
In the case where a resolver implementation supports RSASHA256 and
RSAMD5, if the trust chain using RSASHA256 is broken, validation would
succeed via RSAMD5 if a chain of trust can be established using that
algorithm. This opens a risk of downgrade attack.
It seems better to remove support for older algorithms, if current
algorithms are supported.
I also don't think highly of the RFC behavior that a zone is considered
unsigned if no algorithm is supported in the DS set. It doesn't sit well
with the rest of the all-or-nothing DNSSEC behavior.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
