Re: [DNSOP] [Ext] DNSSEC Strict Mode
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 01 March 2021 18:46 UTC
Return-Path: <ietf-dane@dukhovni.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 187903A212B for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 10:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Eov9OpsJT_Xb for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 10:46:40 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A0D633A2129 for <dnsop@ietf.org>; Mon, 1 Mar 2021 10:46:40 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 9751EC3F94; Mon, 1 Mar 2021 13:46:39 -0500 (EST)
Date: Mon, 01 Mar 2021 13:46:39 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <YD02jymoZ74Wq3gs@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <4009A6F4-26D8-4CC7-8A8D-E0E9041CEC84@wisser.se> <7EB466C7-12BB-4CF9-AF70-E6F8CF2DDEBE@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7EB466C7-12BB-4CF9-AF70-E6F8CF2DDEBE@hopcount.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PI3m3n31jtm-EZjzBGlh6F0FH7Y>
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: Mon, 01 Mar 2021 18:46:42 -0000
On Mon, Mar 01, 2021 at 08:14:20AM -0500, Joe Abley wrote: > We can try harder and harder to shoe-horn DNSSEC into products that > don't easily accommodate it, for sure. However, there's an attendant > risk that by doing so all we really achieve is making DNSSEC more > operationally complex than it already is, and I think there's an > argument that such an outcome would not make it easier to deploy. I does seem that Ulrich is arguing for updates to the specification that relax constraints that contribute the operational challenges. So, if anything, he's also working to reduce operational complexity. > > As a larger entity you might have compliance requirements for dnssec. > > [As an entity large enough to pay significant fees for enterprise DNS > service, the reality today is that you probably don't use DNSSEC at > all.] Yes, presently DNSSEC is enabled on ~5% of domains, and the large enterprise domains are under-represented. That's starting to change in northern Europe (particularly .DK, .NL and .SE), and we just saw on dns-operations that e.g. irs.gov (yes, not a corporate enterprise) in the US both publishes and validates DNSSEC. > > I totally disagree. When has switching off security ever been a smart option? > > If security was the only consideration, then nobody would connect > anything to a network in the first place. I think this is a bit too cynical a response. We're here to take constructive steps to make things better. > > It is only considered smart because the process of moving is so > > complex and error prone. And that is a “feature” of the protocol > > design. It’s not a law of nature. We could change the design to > > allow for secure transfer. > > ... and by doing so we could increase the complexity somewhere else. Or not, there is no prior reason why it should be so. > I'm really just pushing back on the idea that going insecure for a > planned, controlled period of time is necessarily a terrible idea. I > often see these kinds of reactions from people seeing particular > security measures as binary options, instead of taking a more holistic > and risk-based approach, which is why my knee is jerking (I'm not > suggesting that you are one of them). Ah, this is fair, we should both work towards making it easier to not go insecure temporarily, and not sneer at the option of doing so. > If I rely upon a DNS vendor to sign my zone and I want to change > vendors for some business reason, being able to switch easily at the > cost of going insecure for 6 hours might be a much better answer than > not being able to switch at all, or even having the cost of switching > amplified by 100 person-hours of planning, or dealing with the risk of > going dark to users downstream of 8.8.8.8 when it turns out that the > change triggers another corner-case in Google's code base. There is a potential complication if there are business partners or similar to whom one has made commitments to sign one's domain, and e.g. publish TLSA records, ... With the business partners configured to require DNSSEC validation for some set of network services. In that case going insecure is still an outage. We really should be able to have a minimally painless process of moving from one DNSSEC provider to another. Ulrich's suggestions make sense in that light. And yet, we also should not sneer at the choice of going insecure, it just should not be the only (and ideally not most preferred) option. -- Viktor.
- [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode Petr Špaček
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Samuel Weiler
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Brian Dickson
- Re: [DNSOP] DNSSEC Strict Mode Ralf Weber
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Brian Dickson
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Wes Hardaker
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Joe Abley
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Samuel Weiler
- Re: [DNSOP] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Bob Harold
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Joe Abley
- [DNSOP] Fwd: [Ext] DNSSEC Strict Mode Ulrich Wisser
- [DNSOP] signalling mandatory DNSSEC in the parent… Jim Reid
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ben Schwartz
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Paul Wouters
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Havard Eidnes
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ben Schwartz
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser