Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

[Mukund Sivaraman <[e-mail]>]

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