IETF Logo Mail Archive

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

Philip Homburg <pch-dnsop-2@u-1.phicoh.com> Tue, 28 March 2017 10:38 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8E1294D1 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 03:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skIAMpe2WMUX for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 03:38:00 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C8DC6129353 for <dnsop@ietf.org>; Tue, 28 Mar 2017 03:37:59 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1csoVf-0000FDC; Tue, 28 Mar 2017 12:37:55 +0200
Message-Id: <m1csoVf-0000FDC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Tony Finch <dot@dotat.at>
From: Philip Homburg <pch-dnsop-2@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
References: <58D96BC0.9040701@redbarn.org> <20170328024127.GC96991@isc.org> <alpine.DEB.2.11.1703281035190.13590@grey.csi.cam.ac.uk>
In-reply-to: Your message of "Tue, 28 Mar 2017 11:01:01 +0100 ." <alpine.DEB.2.11.1703281035190.13590@grey.csi.cam.ac.uk>
Date: Tue, 28 Mar 2017 12:37:54 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9mYPdyIpibtsauoOcJK6ILooE-w>
Subject: Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 10:38:02 -0000

In your letter dated Tue, 28 Mar 2017 11:01:01 +0100 you wrote:
>Evan Hunt <each@isc.org> wrote:
>>
>> 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.
>
>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).

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.

v2.23.0 | Report a Bug | By Email