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

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Mar 2017 12:45:04 -0700

evan hunt of isc just spoke at the microphones and said "an md5
validator implementation that isn't used isn't hurting anybody." on
pressure of time, the microphones had closed, so i'm commenting here.

i disagree. all code has bugs, eventually. or at least, there is no
existence proof to the contrary, and also, no reason to suspect
otherwise. so, code that is not used will not be reviewed or maintained.
it's a risk, just by existing.

also, a validator that outputs "secure" based on MD5 inputs is making a
promise it can't keep. noone should believe such an output, but there is
no way to signal such a policy -- other than by removing the code point,
and the code that implements it.

-- 
P Vixie

---

From: Jim Reid <[email-masked]>
Date: Mon, 27 Mar 2017 22:10:18 +0100

> On 27 Mar 2017, at 20:45, Paul Vixie <[email-masked]> wrote:
> 
> all code has bugs, eventually. or at least, there is no

+1. The most reliable and safest code is the code that isn't there.

---

From: George Michaelson <[email-masked]>
Date: Mon, 27 Mar 2017 16:16:30 -0500

also +1.

if we define them beyond deprecated to REMOVED then we get some
confidence its the pool of dead code who remain at risk, should
threats emerge.

if we leave them in validation, we can't tell if 'modern' technology
is exposed to risk we didn't understand as attacks get better.

RC4 got removed from browsers. RC4 got removed from OpenSSH. I know
we're a different crypto use-case, but I think we should reflect on
this.

-G

On Mon, Mar 27, 2017 at 4:10 PM, Jim Reid <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Evan Hunt <[email-masked]>
Date: Tue, 28 Mar 2017 02:41:27 +0000

On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote:
> 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.

We can and should kill MD5 key generation and signing (and I'll add this to
the ticket about updating defaults in BIND) but I'm uncomfortable killing
MD5 validation until I'm sure there aren't any legacy keys floating around.

Your other point about never-used code being uneploded ordnance is well
taken.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 28 Mar 2017 02:43:00 +0000

Oopsie:

On Tue, Mar 28, 2017 at 02:41:27AM +0000, Evan Hunt wrote:
> MD5 is known to be breakable, but it's not *as* breakable

as a zone

> that hasn't been signed

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 28 Mar 2017 08:35:23 +0530

Hi Evan

> 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

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Mar 2017 11:01:01 +0100

Evan Hunt <[email-masked]> wrote:
> signed, or a resolver that hasn't turned on validation.

If you haven't seen PoC||GTFO 0x14, run over to
https://www.alchemistowl.org/pocorgtfo/ and have a read.

It features Postscript, PDF/JPEG, and GIF MD5 quines (where the MD5 hash
of the document appears in the text of the document itself) and is itself
an MD5 quine in two different ways (PDF and NES ROM polyglot).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, South Rockall: Southerly or southeasterly 4 or 5 increasing 6 or 7,
perhaps gale 8 later in west. Moderate or rough, becoming rough or very rough
later. Showers then rain. Moderate or good, occasionally poor.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Mar 2017 12:37:54 +0200

>an MD5 quine in two different ways (PDF and NES ROM polyglot).

What makes it bad in the case of DNSSEC is that in various ways DNSSEC
validators indicate to the user that a result is validated without also 
reporting the algorithm(s) used.

So for any piece of client code that takes a security decision based on that
data, allowing weak algorithms or parameters means that either all of DNSSEC
should be treated as insecure, or potentially insecure configurations are
without warning treated as secure.

So if would be best if a validator that implements MD5 would still return 
NXDOMAIN is validation fails, but would keep the AD-bit clear even if validation
passes for a domain signed using MD5.

---

From: Jan Včelák <[email-masked]>
Date: Tue, 28 Mar 2017 13:46:36 +0200

> MD5 validation until I'm sure there aren't any legacy keys floating around.

Short history of MD5 in DNSSEC:

1999: RFC 2535 makes MD5 recommended for DNSSEC
2001: RFC 3110 makes MD5 not recommended for DNSSEC
2004: RFC 3755 disallows MD5 for zone signing
2005: RFC 4034 reassures that MD5 is not recommended and must not be
used for zone signing

DNS software that supports MD5 for zone signing in 2017 belongs to
museum. It's too late for arguments about keeping it for legacy
reasons. I agree that modern validators should treat MD5 as unknown
algorithm.

Jan

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 28 Mar 2017 08:48:48 -0500

On 27 Mar 2017, at 21:41, Evan Hunt wrote:

> MD5 is known to be breakable

Please: let's be careful with our wording here.

There are widely-understood and widely-implemented attacks on MD5's 
collision resistance, reducing it from the design-level of 2^64 to 
somewhere around 2^30. In other words, it is trivial to create messages 
that have MD5 collisions.

To date, there have been no public papers showing any preimage attacks 
on MD5 reducing its design-level of 2^128. There may be privately-known 
attacks, of course, just as there might be for any cryptographic 
algorithm. A researcher who shows a preimage attack on MD5 would get 
huge recognition within the cryptographic community, so there is a 
strong motivation to try. So far, none has been forthcoming.

To date, no one has publicly described how a collision attack would help 
an attacker in DNSSEC. Such an attack would be *very* interesting to 
this community. If you know of such an attack, please say so here or in 
a cryptographic forum.

It has been over a decade since the collision-based attack on PKIX 
certificates was described, but since then none has been described for 
DNSSEC. In specific, because we now know that collision attacks on SHA1 
are feasible and will probably get better over time, this community 
should understand how such an attack could affect us.

For more information on cryptographic attacks on hashes, please see RFC 
4270.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Mar 2017 15:36:40 +0100

Chris Thompson just mentioned to me another reason for dropping support
for RSAMD5: it uses a different DNSKEY tag calculation, which implies that
dropping support should simplify validators more than dropping other
algorithms.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties: Variable 3 or 4. Slight or moderate. Drizzle, showers later. Moderate
or good, occasionally poor.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 28 Mar 2017 15:05:03 +0000

> dropping support should simplify validators more than dropping other

To be clear, for the benfit of those not in the room yesterday, I do *not*
object to deprecating RSAMD5, I agree with the "MUST NOT" in the signer
column, and that it's pointless to support it in new validator
implementations.

My problem is with elevating "pointless" to the force of a "MUST NOT".  I
think it should be reduced in force to "OPTIONAL", "NOT RECOMMENDED", or
even "SHOULD NOT".  Kill it on the supply side.

---

From: Jim Reid <[email-masked]>
Date: Tue, 28 Mar 2017 16:19:59 +0100

> On 28 Mar 2017, at 16:05, Evan Hunt <[email-masked]> wrote:
> 

A "MUST NOT" should kill it on the supply side. Anything less emphatic than that will not. An "OPTIONAL" or whatever creates enough uncertainty to give implementers/operators the idea that it's advisable to persevere with MD5 support "just in case", even if nobody is using MD5. Softer language would give enough wiggle room to allow MD5 support to lurk around forever in a zombie state and never get killed.

Give MD5 support two shots to the head. With silver bullets. Then nuke it from orbit. Just to be absolutely sure.

---

From: Petr Špaček <[email-masked]>
Date: Tue, 28 Mar 2017 17:32:27 +0200

> column, and that it's pointless to support it in new validator

Thank you for clarification!

> even "SHOULD NOT".  Kill it on the supply side.

Here I have to agree with enforcing "MUST NOT". MD5 is a risk even on
the validating side. It might provide attacker with ability to forge
TLSA records in zones signed with MD5, which is has much worse
consequences than treating the zone as unsigned. It is a security
nightmare because validators supporting MD5 will treat this as valid and
happily accept forged certificates!

IMHO validator going to insecure mode is the right thing to do.
Applications are used to insecure records but there is no way to handle
seemingly (but not factually) "secure" records.

So again, MUST NOT is the right choice. I'm going to write tests for
Knot Resolver to ensure we never set AD bit for zones signed using MD5.
Right now.

-- 
Petr Špaček  @  CZ.NIC

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Mar 2017 10:47:54 -0500

> Knot Resolver to ensure we never set AD bit for zones signed using MD5.

If you want to accomplish this, why not actually follow the MUST NOT and remove MD5 support so it is treated as unsupported algorithm and also won't get an AD bit? That way your code has no MD5 specific handling.

Also, as PaulH reminded people, MD5 != HMAC_MD5 and I'd be shocked to see a forged MD5 signature.

Paul

---

From: Petr Špaček <[email-masked]>
Date: Tue, 28 Mar 2017 17:49:49 +0200

> If you want to accomplish this, why not actually follow the MUST NOT and remove MD5 support so it is treated as unsupported algorithm and also won't get an AD bit? That way your code has no MD5 spe…

Sure, my message did not mention any special handling at all.
The test will make sure it is removed and stays removed :-)

-- 
Petr Špaček  @  CZ.NIC

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 28 Mar 2017 19:23:16 +0200

Hi Philip,

> passes for a domain signed using MD5.

In the interest of nitpick correctness, please return SERVFAIL there, 
not NXDOMAIN :)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Evan Hunt <[email-masked]>
Date: Tue, 28 Mar 2017 20:57:08 +0000

Earlier today Petr Špaček sent me an off-list comment that he intended
to be on-list, and I want to promote it:

> happily accept forged certificates!
 
This is a convincing argument, and I'm reconsidering my objections in
light of it.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Mar 2017 11:05:02 +0200

>In the interest of nitpick correctness, please return SERVFAIL there, 

Indeed. Though if somebody is foolish enough to sign with MD5, maybe they should
get a NXDOMAIN :-)