Re: [DNSOP] [Ext] DNSSEC Strict Mode

Joe Abley <jabley@hopcount.ca> Mon, 01 March 2021 13:14 UTC

Return-Path: <jabley@hopcount.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 298A83A1BE5 for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 05:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.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 5WmLAFTBPw05 for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 05:14:25 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECF63A1BE2 for <dnsop@ietf.org>; Mon, 1 Mar 2021 05:14:24 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id w6so11903620qti.6 for <dnsop@ietf.org>; Mon, 01 Mar 2021 05:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=I7q0BGHKXXb6Mg/vYNx16A2M7lMvGPXxzrW/SMoWpV0=; b=Kt/1rPAJh9QqYCHwT+sbD1DEiufaYxQox9K4QXeNZT8IlAbwf+edsqPapXZkSZa0np bpSCtLLyP6nYF2tHiDqGNRRjocZG3QRVeJ2G3e9sYi8n2nIycYrkk/OQ7qu/wAeSAbgj X/dgf2l5W0oA4H71YcbjjEq04BH76x5yYxt/k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=I7q0BGHKXXb6Mg/vYNx16A2M7lMvGPXxzrW/SMoWpV0=; b=nhH9QHgzU6FUQpW+nJB5S6OyjYUjCuUTOosFXdlSIgNBs36f7lb9a4B6cDjj5rQMRg 7qRD3wGgGWmoUjnv902RlRIjdkPlrwmIKqqevQWZGw51a6CevrroUAohh+0PtHw0nTdV k5U5365MZxLkNUQRC4/FZzzeQ7+zICPXaMe5jDHeUU9AsPpbJ/HLnfpdC98Oj7zmm72I lRA2PrGyvTPNfK+PkiHFjaHq6eFnmSU0nUkRH7BhMZBLTXTkoVb8NYhQ0X2hmtAeKvOz 5gPcxdu15rFu3CVUCMUAEot319/S8HCXAmleR4yJYTPYT6N81PFLZ4bjbNa3k9W95cKi XuAQ==
X-Gm-Message-State: AOAM530swTiFjcyjU3j456XoMwjT5AdCVkf0q4iRuYgqUuf3dAvMCrMT OGdA7bhMYYozpPHex9GR/6+zqQ==
X-Google-Smtp-Source: ABdhPJzZybnbfU3+2vGJmAd44VPq+WGAY5DNGyzcB8LhWt99HGoAMcdj3F/U89mgM4+WY4Bf7QsunA==
X-Received: by 2002:ac8:5251:: with SMTP id y17mr12950809qtn.367.1614604462777; Mon, 01 Mar 2021 05:14:22 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:c7:7d70:bc09:cc74:5a87? ([2607:f2c0:e784:c7:7d70:bc09:cc74:5a87]) by smtp.gmail.com with ESMTPSA id i5sm12657461qkg.32.2021.03.01.05.14.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Mar 2021 05:14:22 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-EC25F291-2215-4306-AB75-50B1858C63A6"
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Mon, 01 Mar 2021 08:14:20 -0500
Message-Id: <7EB466C7-12BB-4CF9-AF70-E6F8CF2DDEBE@hopcount.ca>
References: <4009A6F4-26D8-4CC7-8A8D-E0E9041CEC84@wisser.se>
Cc: Mark Andrews <marka@isc.org>, Ben Schwartz <bemasc@google.com>, Paul Hoffman <paul.hoffman@icann.org>, Samuel Weiler <weiler@watson.org>, dnsop <dnsop@ietf.org>
In-Reply-To: <4009A6F4-26D8-4CC7-8A8D-E0E9041CEC84@wisser.se>
To: Ulrich Wisser <ulrich@wisser.se>
X-Mailer: iPad Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JxxQXc7AP53xhHRmvScirgJ3xDE>
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 13:14:27 -0000

Hi Ulrich,

On Mar 1, 2021, at 05:43, Ulrich Wisser <ulrich@wisser.se> wrote:

> On 25 Feb 2021, at 16:11, Joe Abley <jabley@hopcount.ca> wrote:

> 

>> On Feb 25, 2021, at 06:53, Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org> wrote:

>> 
>>> But this is a real world problem, one that is holding DNSSEC back.
>>> If you buy DNS operations the operator will usually tell you what algorithm they use, you have no choice in that.
>> 
>> This feels like one of those areas where more specificity is needed. "DNS operations" is is over-broad; what you mean, I think, is "if you outsource zone-signing". If you sign yourself and distribute your zone to external DNS operators then you can add and drop vendors without worrying about key rollovers, for example.
> 
> Ok, I can be more specific. 
> 
> As a small business owner you have no way to move your hosting company to change their DNSSEC configuration. (Besides that you most probably have no idea that it exists.) You should be able to switch hosting providers without thinking about security, a secure transition should be guaranteed by the hosting companies, who can only do it if it is enabled by the protocol.

Even this really requires more specificity. What is a "hosting company"?

I think a lot of the problems we face with these kinds of scenarios is that various functionally-overlapping industries have sprung up without DNSSEC being much more than an afterthought in the way that products are structured and sold. It's perhaps unremarkable that the mechanics of offering these services are not a great fit.

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.

> 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.]

>> DNSSEC is normally part of a layered set of defences. In such an architecture relaxing one layer for a period in order to fix a problem or avoid a more complicated transition can be a perfectly acceptable answer. Going insecure for a short period in that context is not necessarily a cop-out; it could well be smart thinking.
> 
> 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.

> 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.

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).

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.

To the end-user, I can see why having a protocol element designed to make this easier and avoid the practical need to go insecure seems highly attractive, but we're really just shifting the cost of dealing with what might very well be a somewhat rare corner case to the developers, operators and users of every DNS server that supports DNSSEC. Even if the costs are low in the latter case, I think it's reasonable to say they are non-zero and universal, which means they might not be so low in aggregate.

In this context, the determination of what is smart and what is silly seems a little more grey to me than your message ("totally") suggests.


Joe