IETF Logo Mail Archive

Re: [DNSOP] [Ext] About key tags

Edward Lewis <edward.lewis@icann.org> Wed, 28 February 2024 20:59 UTC

Return-Path: <edward.lewis@icann.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 7CD52C14F699 for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2024 12:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 BI9mcA5mpDC5 for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2024 12:59:30 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 0FBA2C14F5E3 for <dnsop@ietf.org>; Wed, 28 Feb 2024 12:59:30 -0800 (PST)
Received: from MBX112-E2-VA-1.pexch112.icann.org (out.mail.icann.org [64.78.48.205]) by ppa2.lax.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 41SKxS4S021610 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Feb 2024 20:59:29 GMT
Received: from MBX112-E2-VA-1.pexch112.icann.org (10.217.41.128) by MBX112-E2-VA-2.pexch112.icann.org (10.217.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Wed, 28 Feb 2024 15:59:27 -0500
Received: from MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) by MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) with mapi id 15.02.1258.028; Wed, 28 Feb 2024 15:59:27 -0500
From: Edward Lewis <edward.lewis@icann.org>
To: John Levine <johnl@taugh.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] About key tags
Thread-Index: AQHaXynPA8WwwMruZU6Z5RM+17D0wbEJySsAgACGD4CAAStKgIAASjQAgAA/RYCAAAE9gIAAAsCAgADi3oCAAGiXgIAAGREAgAAQ2wCAEXRUAIAAJ+KAgAAPFICAASsOAA==
Date: Wed, 28 Feb 2024 20:59:27 +0000
Message-ID: <641C2E38-F1A8-435B-BA6F-770FEE9AEEA5@icann.org>
References: <9C4B65D7-EC9D-40BC-9B23-825F7FE8FB7E@isc.org> <20240227220905.E06018410007@ary.qy>
In-Reply-To: <20240227220905.E06018410007@ary.qy>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.65.22091101
x-originating-ip: [192.0.47.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <5506A66E1085924BA77F388DC2273BB4@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-28_08,2024-02-27_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WYCiVO7uh-uH8THdf4f9HXA1QgU>
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 20:59:30 -0000

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.

v2.23.0 | Report a Bug | By Email