Re: [DNSOP] [Ext] About key tags

Mark Andrews <marka@isc.org> Wed, 28 February 2024 21:25 UTC

Return-Path: <marka@isc.org>
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 88C5FC14F708 for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2024 13:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.408
X-Spam-Level:
X-Spam-Status: No, score=-4.408 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_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=isc.org header.b="VANVVwqL"; dkim=pass (1024-bit key) header.d=isc.org header.b="JoFWLSLh"
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 panhbZf9lxJO for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2024 13:25:19 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC5EC14F60D for <dnsop@ietf.org>; Wed, 28 Feb 2024 13:25:18 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 4256B3AB1B7; Wed, 28 Feb 2024 21:25:18 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 4256B3AB1B7
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1709155518; cv=none; b=Pl0EoF4ESlqICaxAxu/2AjVI0440lyh6UWFobqXfKSSd+V6VCbGJFMzm4Y1Ig3ChtdMxQthINYGxA+3wM+VjApsN2dztFZVIJSuCCSJhN8Zrf9/ySJeawpCh4hgFtTU/KrT5shTo+OYwN9YkPuDOscl4bYvJsxmFhv5VEN7oW4o=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1709155518; c=relaxed/relaxed; bh=oy/1C3Ih/ANT/kUYjHsFVwRZxClCK22v62NrQOixRHU=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=AaEaaSyE3WSrvlmOSr9ZI2yC487GIh+u4aGXvooiCNGgREEyKdJaPSBtiWDkogRl01oEjDUjhAXT5ok3tbqQQlT6ZrKUKAcNNt9ViNPmNT8ZckCrpED9vtq182bWJjg2LGOVg/c/6rSXeA55fg67u/s75h+x3VVbyeBhHvyPjsE=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 4256B3AB1B7
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1709155518; bh=He07+R5zmGOl91Kn7NSocNCcFQJ2Pqil0et5Dm13zkA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=VANVVwqLV4xDYFE9rEZ/uqpUz6YNofxopxnc5kUkOpUXeoi8771ti7XbYAH4Gw/CD tjSUnBqV0pjyPTJzbo/c8yUzsk/2kRIiFILnAgXU1ZIsvkQEeCLub3n+W+8PAgNTPy 58+upofZTC3qVqo2c/Ui9ExVCCxfvUAsfePL+LI0=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 3DFFA36C41C; Wed, 28 Feb 2024 21:25:18 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 1A1671120CBC; Wed, 28 Feb 2024 21:25:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 1A1671120CBC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1709155518; bh=oy/1C3Ih/ANT/kUYjHsFVwRZxClCK22v62NrQOixRHU=; h=Mime-Version:From:Date:Message-Id:To; b=JoFWLSLhzodd3tHX520NxOSol1OkOwemEaEF1eQCxTW13NiAh09Nxja9JBRIGr6aS rgcbDN2JCNA9ymz184Jbh470u1efnTVfWUroSXZ6Xnn2tCj3+8E5JiIP1dcAY4OazL vFXVl+V5Hlo/z4WjfBbszj2Ze5LOgjNtmgIfn4Hc=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id QRdGbwVFztuA; Wed, 28 Feb 2024 21:25:18 +0000 (UTC)
Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id 51B7C36C41C; Wed, 28 Feb 2024 21:25:17 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <641C2E38-F1A8-435B-BA6F-770FEE9AEEA5@icann.org>
Date: Thu, 29 Feb 2024 08:25:04 +1100
Cc: John Levine <johnl@taugh.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <424DEFFC-0836-4C6E-842A-F2B332459A8B@isc.org>
References: <9C4B65D7-EC9D-40BC-9B23-825F7FE8FB7E@isc.org> <20240227220905.E06018410007@ary.qy> <641C2E38-F1A8-435B-BA6F-770FEE9AEEA5@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qU9Ul0vJvHYzmkJKklxHviebx-Q>
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 21:25:23 -0000


> On 29 Feb 2024, at 07:59, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> On 2/27/24, 17:09, "DNSOP on behalf of John Levine" <dnsop-bounces@ietf.org on behalf of johnl@taugh.com> wrote:
> 
>>   The kind of load is different but in each case the client needs to
>>   limit the amount of work it's willing to do. We can forbid it in the
>>   protocol but unless you have better contacts at the Protocol Police
>>   than I do, people will do it anyway.
> 
> I side with John Levine's line of reasoning, that the solution is defending against taking on too much work (in this case, the validator caps it's effort - in whatever way is appropriate).  It would be futile to prevent key tag collisions from happening via a protocol change as a malicious actor is not bounded by specifications.
> 
> If it is forbidden in the protocol, it might still happen.

Ed, your reasoning is off.  The point of forbidding is to allow the validator to safely stop as soon as possible when it is under attack.

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org