IETF Logo Mail Archive

Re: [DNSOP] signalling mandatory DNSSEC in the parent zone

Paul Wouters <paul@nohats.ca> Mon, 01 March 2021 16:37 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 8505E3A1F56 for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 08:37:46 -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=ham 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 iEwbbzKMcfUO for <dnsop@ietfa.amsl.com>; Mon, 1 Mar 2021 08:37:45 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 5394F3A1F39 for <DNSOP@ietf.org>; Mon, 1 Mar 2021 08:37:32 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Dq5XB6xQCzCtP; Mon, 1 Mar 2021 17:37:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614616650; bh=L70Rt6WLRsGBlqqcwRxclB617pr//RPe64qDdUvzW3Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ijDaCfwG2vMl63lN7TADfo/qbdWkdmrV4NM0LBi69wKBV28Zs1t2ebqPdbG7UUzgz EdvetjJhglZzGwOhmhNfJxFqqBtevAKbhHQvphyu7jrwjWABYOr2RgrI7Svr47ktUO UzmIyyY8xOd1tY2NdL1ON3G8mCK5x1aPR/Z37YMU=
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 PwS_wtI2iD1Z; Mon, 1 Mar 2021 17:37:30 +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; Mon, 1 Mar 2021 17:37:29 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9F9CC6029B62; Mon, 1 Mar 2021 11:37:28 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9733666B1E; Mon, 1 Mar 2021 11:37:28 -0500 (EST)
Date: Mon, 01 Mar 2021 11:37:28 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
cc: Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org>, dnsop <DNSOP@ietf.org>
In-Reply-To: <CAHbrMsD_4sHSJ_1eRCpBz_+PqfkNvkGgx6Gfe8-OQNBRe5bEZg@mail.gmail.com>
Message-ID: <db017de-c373-474b-8445-f4b011f498ac@nohats.ca>
References: <4C3B1EF7-D37F-40D4-9C39-70FADF2B71CC@wisser.se> <789EBF89-24CC-452A-A1D0-AE5583D6A476@wisser.se> <A148F043-6DC6-47B0-B6B0-F112BF346E73@rfc1035.com> <3679416F-914B-41B5-A8D6-93993BEDA65C@wisser.se> <CAHbrMsD_4sHSJ_1eRCpBz_+PqfkNvkGgx6Gfe8-OQNBRe5bEZg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ov9wMqmQrxeG8c_1I_GAbdopRoo>
Subject: Re: [DNSOP] signalling mandatory DNSSEC in the parent zone
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 16:37:47 -0000

On Mon, 1 Mar 2021, Ben Schwartz wrote:

> Given the existence of MTI algorithms, do we need to be so concerned about operators who support non-overlapping
> subsets?  It seems like the guidance is clear: follow the MTI!

MTI is not mandatory to deploy. If your new DNS operator is fully ECDSA,
and your old one is RSA only, and both are MTI, there is still a
problem to solve.

I still think this is mostly a tooling problem. With the right tools,
the new registrar can give a DNSKEY to the old registrar, who is
mandated by contract to add it to their zone.

The old registrar that is uncooperative, an always break things. eg
simply by decomissioning the domain in question completely from their
namesevers.

Paul

v2.23.0 | Report a Bug | By Email