Re: [DNSOP] [Ext] DNSSEC Strict Mode

Paul Wouters <paul@nohats.ca> Thu, 25 February 2021 17:40 UTC

Return-Path: <paul@nohats.ca>
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 84CCD3A1E30 for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2021 09:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 y6ISZMYZb1JW for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2021 09:39:59 -0800 (PST)
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 144393A1D9D for <dnsop@ietf.org>; Thu, 25 Feb 2021 09:39:52 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Dmg5x6k0Gz5B9; Thu, 25 Feb 2021 18:39:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614274789; bh=/cUAzSmUyXDIPcpVv4lYrWnpBTZUbqY1zEIj0d34lB8=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=llVOs+9qiePuUiMClIK9YCx4K4CTXb1DR2AX5Pvh5jWOrZBAlD0yYvJwH82ysNEhl a//o2YNPbiek4JYmdXo0w/WQ/jijPRDfKxv5iVklPrCV3LucTmHhh45C94byZVjY8x QYYugkfZ7vwM3amc9eQd3aQLJt+i5kg5ax1+fFtU=
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 s_ZS-XFtz-6D; Thu, 25 Feb 2021 18:39:48 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 25 Feb 2021 18:39:48 +0100 (CET)
Received: from [193.110.157.220] (unknown [193.110.157.220]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 54B4D6029BA0; Thu, 25 Feb 2021 12:39:47 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Thu, 25 Feb 2021 12:39:45 -0500
Message-Id: <55277725-FED8-408A-B93D-C75AD1696018@nohats.ca>
References: <CAHbrMsAdbn85AUCY9Yr6XXU-6Ti4dKwR1=zncGj4z-SjznAF3w@mail.gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
In-Reply-To: <CAHbrMsAdbn85AUCY9Yr6XXU-6Ti4dKwR1=zncGj4z-SjznAF3w@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k7hpQGnK0H6VZ8DLzZ5uIlq0rFQ>
Subject: Re: [DNSOP] [Ext] DNSSEC Strict Mode
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 25 Feb 2021 17:40:07 -0000

On Feb 25, 2021, at 11:06, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> 
> 
> That's not especially the intent.  Currently, if you sign with two algorithms, and either of those algorithms becomes insecure*, your zone becomes susceptible to forgery.

Which is why we have RFC 8624 and it’s successors. It really should prevent you from using “insecure” or weak algorithms. The [*] doesn’t really help you. If sha2 is broken and we don’t know it, you wouldn’t know to not use it as “secure”



>   If you mark both algorithms as Strict, then your zone remains secure (for validators who implement both algorithms and this draft).

That cannot be true, unless your draft requires validaties to validate with all algorithms for a double signed zone (also double signed zones are rare and really only transition during a migration)

I’m with Paul H here, I don’t see a use case.

As I think Petr said, we need to make the software do algorithm rollovers easier so people don’t avoid migration.

Paul