Re: [DNSOP] [Ext] DNSSEC Strict Mode

Ulrich Wisser <ulrich@wisser.se> Mon, 01 March 2021 10:43 UTC

Return-Path: <ulrich@wisser.se>
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 461443A19AB for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 02:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.218
X-Spam-Level:
X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wisser.se
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 RH_osY12dX6Q for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 02:43:30 -0800 (PST)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C1E3A19AA for <dnsop@ietf.org>; Mon, 1 Mar 2021 02:43:29 -0800 (PST)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4Dpxgg42PBzQlY9; Mon, 1 Mar 2021 11:43:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisser.se; s=MBO0001; t=1614595405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eoPLORWCAfoeMbGO13zM1rgNtWHy3L0L/Cietp5D1m0=; b=W/nPfzHy+fNfCxLeZwAWlHKKnPAQnRUPGS2oYmZdaANK/ssc6fbpaSBj1Qb4FN0iWWRoas xP30tknYFyb6x6NpPy7PKcP9TkKCKkQik+srRzb8ssv7iRDXeYfWPY9VFNBi6sTxgzEVEC Zb7UjPp6UMq3VEKLfu/ZhGmu3ZCuTVry/KDsVxv4DbhcIWFdxFlBtGOmDhGYcGTEhvUL1h AnJsfSV7Rf6G8DLPjnlyTErCfwejdXx6YwvHAeN5LUmZY7AVAnTL5dGGo4QCTovsJis3c8 8MM0JsYoyKw11DHAvj1fWVhsClyVt+54InaxDWFwPdo+r+JOcwQT6HraJ2Ir4Q==
Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id 3zFKPQKXFp61; Mon, 1 Mar 2021 11:43:23 +0100 (CET)
From: Ulrich Wisser <ulrich@wisser.se>
Message-Id: <4009A6F4-26D8-4CC7-8A8D-E0E9041CEC84@wisser.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E608097-23DD-438C-9ED6-719D471D6D60"
Mime-Version: 1.0
Date: Mon, 01 Mar 2021 11:43:20 +0100
In-Reply-To: <A84CDA86-FB37-4086-AF05-2E25BCB12766@hopcount.ca>
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>
To: Joe Abley <jabley@hopcount.ca>
References: <17704496-1D7E-4891-8ADB-4D6002D070D3@wisser.se> <A84CDA86-FB37-4086-AF05-2E25BCB12766@hopcount.ca>
X-MBO-SPAM-Probability:
X-Rspamd-Score: -4.95 / 15.00 / 15.00
X-Rspamd-Queue-Id: 1B6C817D3
X-Rspamd-UID: eb2a17
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ixionj9Q3v6olbPOa3Lbbax1DnU>
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 10:43:32 -0000


> On 25 Feb 2021, at 16:11, Joe Abley <jabley@hopcount.ca> wrote:
> 
> Hi Ulrich,
> 
> 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.

As a larger entity you might have compliance requirements for dnssec. But at the same time you need to follow public procurement rules. You can not always chose service providers freely. Moving your domain should be secure, going insecure is not an option.


>> Now if your new operator doesn’t use the same algorithm you can’t switch without going insecure.
>> I don’t think this is an acceptable situation.
> 
> I agree that this is a factor that ought to be included in the process of deciding to move vendors. If your proposed new vendor can't do what you want, then presumably you don't move there. While it's always possible to make mistakes, it's not at all clear to me that particular problem is something that needs protocol-level mitigations.
> 
> 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?
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.

> 
> 
> Joe

/Ulrich