IETF Logo Mail Archive

Re: [secdir] secdir review of draft-ietf-dnsop-obsolete-dlv-00

Paul Wouters <paul@nohats.ca> Thu, 26 September 2019 13:32 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09112002F; Thu, 26 Sep 2019 06:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 BMDjoL_jPUZX; Thu, 26 Sep 2019 06:32:15 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9C1B9120827; Thu, 26 Sep 2019 06:32:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46fG7K6gLHzF0T; Thu, 26 Sep 2019 15:32:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1569504733; bh=YidRQTgRupJCUTVHuyo1OV5lBCJBQrlC6vT0zMxQbv8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SbOJOTzagnlJKeXik278F+CDIMUTi1WKA9aoTOtYxmM0r02KOaTxhSC40tGwkTXYm WPkfarrMYhYxBMDfKVMX7OI/0a35kF/wSTJolmj2ZmfPNcm38gxVH0WeeMPMnSgoew hsPrIWr/PyLyfDuRWZ0ZFaMhnVSXBikxYHDrbBt8=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yYIWJgGMc2dV; Thu, 26 Sep 2019 15:32:12 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 26 Sep 2019 15:32:12 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8AC87322DE9; Thu, 26 Sep 2019 09:32:11 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8AC87322DE9
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 808BD40D37E1; Thu, 26 Sep 2019 09:32:11 -0400 (EDT)
Date: Thu, 26 Sep 2019 09:32:11 -0400
From: Paul Wouters <paul@nohats.ca>
To: "Scott G. Kelly" <scott@hyperthought.com>
cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-dnsop-obsolete-dlv.all@ietf.org
In-Reply-To: <1569504030.247815945@apps.rackspace.com>
Message-ID: <alpine.LRH.2.21.1909260926140.2865@bofh.nohats.ca>
References: <1569504030.247815945@apps.rackspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/I5bNM7jTCrOchToIcd8OWgtPjGI>
Subject: Re: [secdir] secdir review of draft-ietf-dnsop-obsolete-dlv-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 13:32:24 -0000

On Thu, 26 Sep 2019, Scott G. Kelly wrote:

> I'm not a DNSSEC expert, so maybe this is a dumb question, but is there any possibility that someone doesn't get the memo, and continues to rely on some not-so-well-known DLV registry? And if so, what could happen as a result? Anything anyone should care about?

It is possible someone has spun up a private DLV none of us knows about.
They will at some point upgrade their software and see it is no longer
working. Some of their queries will potentially change from secure to
insecure. It is highly unlikely this would cover any public domains,
because those queries would also be insecure for anyone not using that
DLV, and it would already be too fragile to rely on getting nameservers
assigned on roaming devices that would chain back to a resolver that
uses this private DLV.

So it would be a very fragile infrastructure that goes from fragile to
insecure.

I think the short warning in Section 5 is enough to discuss this case.

Paul

v2.23.0 | Report a Bug | By Email