Re: [DNSOP] [Ext] DNSSEC Strict Mode

Viktor Dukhovni <> Fri, 26 February 2021 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C5813A0E09 for <>; Fri, 26 Feb 2021 14:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CHkqlcuuiFMU for <>; Fri, 26 Feb 2021 14:26:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AB5A3A0E0A for <>; Fri, 26 Feb 2021 14:26:07 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0A091C2751 for <>; Fri, 26 Feb 2021 17:26:07 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Fri, 26 Feb 2021 20:26:06 -0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] [Ext] DNSSEC Strict Mode
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 22:26:10 -0000

> On Feb 26, 2021, at 5:58 PM, Ben Schwartz <> wrote:
> I agree.  The Strict Mode draft is, in a sense, based on the pessimistic assumption that we won't be able to sufficiently improve these practices, so we'll need to be able to tolerate second-rate signature algorithms.  That could be because of outdated clients, postquantum concerns, or conflicting national crypto requirements.  Also, the bar will be higher if we believe that DNSSEC is not only for partial defense and special uses, but a global security layer on par with HTTPS.
> It's clear that the working group is not convinced.  That's fine!  As long as everyone is aware of the challenge, we can revive this approach if it becomes necessary.

I am much closer to convinced than it may appear.  The protocol
is logically and technically sound.  I hesitate primarily because
I think we're not doing the basics well enough yet to set the bar
even higher, and users are likely to make mistakes.  I'd like to
revisit this proposal as use of DNSSEC expands and we start to
expect more from operators and we see evidence that practices
have improved to a point where we might legitimately worry about
downgrades as much as about operational errors.