IETF Logo Mail Archive

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Jim Reid <jim@rfc1035.com> Wed, 06 January 2021 21:12 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 8D8283A11E4 for <dnsop@ietfa.amsl.com>; Wed, 6 Jan 2021 13:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 8Yfl3WnM9Ltc for <dnsop@ietfa.amsl.com>; Wed, 6 Jan 2021 13:12:58 -0800 (PST)
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 468EF3A1120 for <dnsop@ietf.org>; Wed, 6 Jan 2021 13:12:57 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 1F0FA2421544; Wed, 6 Jan 2021 21:12:56 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <CAHbrMsC+Et+iva-3Z1dqHn0HO_njhJT3q-gmoJcyopML_WDCWw@mail.gmail.com>
Date: Wed, 06 Jan 2021 21:12:54 +0000
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F22EF63C-A3EE-4D68-859B-35B524CC8F24@rfc1035.com>
References: <CAHbrMsDAMsXzAhcu35_GqL54JNF2jO-HhYWEZyE2VLP=V8dN5A@mail.gmail.com> <9F0E83E0-EAB1-4508-9D55-850294204BD2@hopcount.ca> <CAHbrMsC+Et+iva-3Z1dqHn0HO_njhJT3q-gmoJcyopML_WDCWw@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gKq1aKXNirJAvSY_jCXqn0ejObU>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
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: Wed, 06 Jan 2021 21:13:00 -0000


> On 6 Jan 2021, at 20:48, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
>> > Telling validators to "insist" that all signatures are valid would resolve this dilemma.  Zone owners could add algorithms without weakening anything.
>> 
>> How do you deploy a new signing algorithm alongside an established one without going dark to users using validators that don't support it, in that case?
>> 
> To clarify, I meant "all signatures under algorithms that are implemented by the validator", i.e. "check everything you can".

??? Are you saying validators should check every RRSIG for each algorithm that they support even after they’ve found one of these RRSIGs that validated?

v2.23.0 | Report a Bug | By Email