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

Jim Reid <jim@rfc1035.com> Tue, 28 March 2017 15:20 UTC

Return-Path: <jim@rfc1035.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 C4BCB129687 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 08:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 T-ROidZcKFj5 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 08:20:05 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3D612953A for <dnsop@ietf.org>; Tue, 28 Mar 2017 08:20:05 -0700 (PDT)
Received: from dhcp-8770.meeting.ietf.org (dhcp-8770.meeting.ietf.org [31.133.135.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 77747242102F; Tue, 28 Mar 2017 15:20:03 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <20170328150503.GA21064@isc.org>
Date: Tue, 28 Mar 2017 16:19:59 +0100
Cc: IETF dnsop Working Group <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <701B217C-9999-452C-8CFD-11D778C02752@rfc1035.com>
References: <58D96BC0.9040701@redbarn.org> <20170328024127.GC96991@isc.org> <CAM1xaJ-gCKqm63BuNszLxyt0_HevXSwB5H0+wg4ugatZSFJNPA@mail.gmail.com> <alpine.DEB.2.11.1703281532260.13590@grey.csi.cam.ac.uk> <20170328150503.GA21064@isc.org>
To: Evan Hunt <each@isc.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/w9lHNu3cerzPS1phgMimuKHT0Co>
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 15:20:07 -0000

> On 28 Mar 2017, at 16:05, Evan Hunt <each@isc.org> wrote:
> 
> 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.

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.