Re: [DNSOP] [Ext] About key tags

Peter Thomassen <peter@desec.io> Tue, 27 February 2024 18:52 UTC

Return-Path: <peter@desec.io>
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 E0B91C14F71C for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 10:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCXATEWqr7gF for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 10:52:35 -0800 (PST)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EB9C14F60A for <dnsop@ietf.org>; Tue, 27 Feb 2024 10:52:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=34hFzpN5Iyd5hbKye+9JhEq1xW2w1peZC/JDTQLpZvM=; b=wgNMDb3LfpvKaOyuDCIKufMkX9 aTd5ieueG2lI8/4d39gx1uNb5wMY/XiQq+E8uBFFDiINBZcC/Mu8qIeygOaGH0MXiC3b7tWWl81Ko 6V7xg+zbD4UXjxOnut/hogMna5asqn2NzdM7IEKsiEgMoPoYjjrS91Eo2bx/VIQl9+cUb0ZDXNO/E nfXGPfTx9YIuMmUeJw83buxlpZl4ZlK/mikhx3eIDgaYd0YnhmWkNM/m/kTZBCmVEvIKNBdlcnuer uBoa7DGTGPPJbLWKAGZjxM4qyOieMfxOQEOURJGxEKnMYY95CMYIfzxYoQ15VKnkvLHhttkkXLHiN pjbdbtYg==;
Received: from [2a00:20:d005:71ab:560c:c764:9d46:3f82] by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1rf2Z1-003f55-UX; Tue, 27 Feb 2024 19:52:28 +0100
Message-ID: <c5a885e7-0790-4061-8311-a03cb5ac9dee@desec.io>
Date: Tue, 27 Feb 2024 13:52:22 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Jim Reid <jim@rfc1035.com>, Joe Abley <jabley@strandkip.nl>
Cc: IETF DNSOP WG <dnsop@ietf.org>
References: <AB885381-32F3-4CEA-8FA9-9E727EABCB5A@rfc1035.com> <662C2C75-EB81-42DB-94E0-822360B0664E@strandkip.nl> <2352E7C1-DF06-4548-AF3F-F643481991F1@rfc1035.com>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <2352E7C1-DF06-4548-AF3F-F643481991F1@rfc1035.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/q2iShvK62Monkv_VmL-dps0kkoY>
Subject: Re: [DNSOP] [Ext] About key tags
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 27 Feb 2024 18:52:40 -0000


On 2/16/24 17:19, Jim Reid wrote:
>> If a zone's signatures and keys are constructed and published in such a way that it causes indigestion in validators, and as a consequence validators fail to return responses for data in that zone, that's a self-inflicted problem and the zone administrator surely has every incentive to fix the problem. If the tools the zone administrator is using make the problem hard to make, then so much the better.
> 
> If validators can also make this problem hard to make, that’s so much the better too. That should give signers a strong incentive to fix their self-inflicted problem and stop hurting validating resolvers.
With (some) validators returning SERVFAIL when encountering a keytag collision, any operator adding a DNSKEY (e.g., for rollover) will, in roughly 2^-16 of cases, break their zone without notice.

It's not clear to me how one would characterize such validator policy as "mak[ing] this problem hard to make".

It rather seems like inviting instability, then telling the signer "well, you knew...! Or should have, at least."

I don't see in what way that's better than what we have with the current fixes, which successfully address the problem and (AFAICS) don't need to be touched again.

Best,
Peter