IETF Logo Mail Archive

Re: [DNSOP] [Ext] About key tags

Paul Wouters <paul@nohats.ca> Wed, 28 February 2024 02:38 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 7CBBBC15152D for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 18:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 (1024-bit key) header.d=nohats.ca
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 pZ-TxMobb4mA for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 18:38:19 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 7103BC14CE36 for <dnsop@ietf.org>; Tue, 27 Feb 2024 18:38:19 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Tkz6v61Xbz37K; Wed, 28 Feb 2024 03:38:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1709087895; bh=2++X24/aFwtDWnx5xzaIgaWuCFwgEFm47dXNf65WpOg=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=P+bXUN8jb+n/qcf5nVIrxByKdmKct6yxUs3b57VHIRixOeJ2EOOssbWxNpjJUkin8 qhmS+YC1nFz/DdwdYdTOpc7/i3kx0R/fcJXrMNik2/9GX9DYEZaybmW720dzFoGRol pbBjKSXLO4CVaH9B9wX8LCVgmO4krtxGcYKlKWXM=
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 hesFhOGy8amP; Wed, 28 Feb 2024 03:38:15 +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; Wed, 28 Feb 2024 03:38:14 +0100 (CET)
Received: from smtpclient.apple (unknown [193.110.157.208]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id F11FD1171A63; Tue, 27 Feb 2024 21:38:13 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Tue, 27 Feb 2024 21:38:02 -0500
Message-Id: <70C3166D-B812-4240-A209-CF984BC3027E@nohats.ca>
References: <447E01C7-C245-4BA3-88C7-AF847B50047A@isc.org>
Cc: John Levine <johnl@taugh.com>, dnsop@ietf.org
In-Reply-To: <447E01C7-C245-4BA3-88C7-AF847B50047A@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (21D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UMYrSiJueygFahFlbRnEgzQEQKc>
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: Wed, 28 Feb 2024 02:38:23 -0000

On Feb 27, 2024, at 17:48, Mark Andrews <marka@isc.org> wrote:
> 
> If you forbid in the protocol

But part of this is not “in” the protocol. Eg if two dns hosters happen to arrive at the same key tag for a single zone in concurrent offline ways. Or if that happens when KSK and ZSK are managed differently.

Your earlier email on what human operators must do to prevent this isn’t really automated.

>  Colliding key tags are a force multiplier when
> trying to DoS a validating resolver.

There are various defence mechanisms, like a longer negative cache for colliding keytag domains, so that the cost isn’t a simple 3x

Paul

v2.23.0 | Report a Bug | By Email