IETF Logo Mail Archive

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

Evan Hunt <each@isc.org> Tue, 28 March 2017 02:41 UTC

Return-Path: <each@isc.org>
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 71289129851 for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 19:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 iXH_qGV4AAV8 for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 19:41:30 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E77128D3E for <dnsop@ietf.org>; Mon, 27 Mar 2017 19:41:30 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 40B6934930F; Tue, 28 Mar 2017 02:41:27 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 3505B216C1C; Tue, 28 Mar 2017 02:41:27 +0000 (UTC)
Date: Tue, 28 Mar 2017 02:41:27 +0000
From: Evan Hunt <each@isc.org>
To: Paul Vixie <paul@redbarn.org>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20170328024127.GC96991@isc.org>
References: <58D96BC0.9040701@redbarn.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <58D96BC0.9040701@redbarn.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ychaTGasP_2uSo6MrBIPoRf9q7w>
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 02:41:31 -0000

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.

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 -- each@isc.org
Internet Systems Consortium, Inc.

v2.23.0 | Report a Bug | By Email