[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC
Mark Andrews <marka@isc.org> Fri, 26 July 2024 23:07 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 7658CC14F5F9 for <dnsop@ietfa.amsl.com>; Fri, 26 Jul 2024 16:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=isc.org header.b="DjiBBxwE"; dkim=pass (1024-bit key) header.d=isc.org header.b="Dd1/HLJ9"
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 KKD_VlYynUut for <dnsop@ietfa.amsl.com>; Fri, 26 Jul 2024 16:07:24 -0700 (PDT)
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 ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BF0C14F5E6 for <dnsop@ietf.org>; Fri, 26 Jul 2024 16:07:24 -0700 (PDT)
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 ED26B3AB271; Fri, 26 Jul 2024 23:07:23 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org ED26B3AB271
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=1722035244; cv=none; b=dlP8Vw2zShjzV/7FOq8RjZOOiSDlqp9C4rQhlFIgJw55wmAXNaXW6x1TgHCYB2z1gomEaSnov+trx6fwyEe0pdKav1NsjPJeXqCZOEhtqPpXf+Ei/m8lvS2DLl9IcOHjAYSojlJr+/WCfyxWtlKloxTTaNRpp4govB4v9YQVBEU=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1722035244; c=relaxed/relaxed; bh=V8hXnE5zyA2LKEGeLRY0ew5s/sabYxNSXeQGXdwn3zM=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=YgniwtdWR1H/1B8Zw67MCzjNT/EOZy/fIqwW4ArxTLuBKC1YAxg6S/MZpLPUZtpBN7FKmSYL0ACXxm5jWggeOENQagCLkUHMEjr6K/tvo2yZAl3QhYKANQ5ZvCi4XIbBalxqnpUmMdIhtvqjIF/ZNQP4pyKJgvPtdki2OffQKjs=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org ED26B3AB271
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1722035244; bh=1gT7oXFvl0hqFymxYMz2KyvB8sx9zQBTofnAmf8cX8w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DjiBBxwExAOOTOBZZNIFsDYO+3DPf4JfdCek7FlS8h5UAMYHHS2FZAcoEYwe5DouB p75zGrFlEGZCfw1m6r6D6oL6Mmq1SwBgbf2D8IW3LZ4/cJsr8WE8qcjd9Pk8aW8lgS MGYZAADDSzGc07Bp75cOsy3rRkpWtEhbdT/poLTs=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id E6074E6E62C; Fri, 26 Jul 2024 23:07:23 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id BD56AE6E8DF; Fri, 26 Jul 2024 23:07:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org BD56AE6E8DF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1722035243; bh=V8hXnE5zyA2LKEGeLRY0ew5s/sabYxNSXeQGXdwn3zM=; h=Mime-Version:From:Date:Message-Id:To; b=Dd1/HLJ9TmkOQjePduY4Ya6TdU5aNMurzaK9YYaSrI8Dao23YxvCwhxMv/tDt3Ig9 Nczt7ja60Q+kXlk6QNQZP67a91XIR//uBzmvFms8Pbrs6WZ/5r7FUIokvSD+gK5BV7 7qqoKUi8ntmLwlco6n34iHE1TB6vqQPF+WwaECwg=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id y4iCNHX6iqE7; Fri, 26 Jul 2024 23:07:23 +0000 (UTC)
Received: from smtpclient.apple (dhcp-9643.meeting.ietf.org [31.133.150.67]) by zimbrang.isc.org (Postfix) with ESMTPSA id 88D90E6E62C; Fri, 26 Jul 2024 23:07:23 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20240726215508.3E424905258C@ary.local>
Date: Fri, 26 Jul 2024 16:07:20 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DA28E74-88A9-4EDB-84D3-F862272072AF@isc.org>
References: <CAHPuVdUveYraaGtrGveKTiLgP1L19G6g6=bsKsHjsPsP5fkiXg@mail.gmail.com> <727BB4FD-2492-4B18-B4DB-80A1C3DFBCD6@icann.org> <20240726215508.3E424905258C@ary.local>
To: "John R. Levine" <johnl@taugh.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Message-ID-Hash: MOL32543TXAEJELL7TILJRB5AUITOGK4
X-Message-ID-Hash: MOL32543TXAEJELL7TILJRB5AUITOGK4
X-MailFrom: marka@isc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>, Paul Hoffman <paul.hoffman@icann.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8sn-h_daJ3UKJdzjqTKUuckldfw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
This expectation setting. Adjusting key generation won’t happen unless there is a written requirement for it to happen. If we where to say duplicate keys tags are no longer supported as of date X there is no way the operators of all the existing signed zones with duplicate tags would know to perform key rolls. We have a chance that when new algorithms are added the key generation software will be updated to enforce uniqueness (for all algorithm). Operators of zones that generate duplicate tags and have the validation fail will not have a leg to stand on with their complaints. "Go tell your vendor to fix their software" will be the response. Even if we where to go with one failure is allowed we still need to write down the new rules and there will be complaints that we are retrospectively changing the rules. This is grand fathering in the old rules for the old algorithms. Mark > On 26 Jul 2024, at 14:55, John Levine <johnl@taugh.com> wrote: > > It appears that Paul Hoffman <paul.hoffman@icann.org> said: >> The problems are listed as: >> >> Colliding key tags impose additional work on a validating resolver, which then has to check >> signatures for each of the candidate set of keys identified by the Key Tag. Furthermore, they >> open up resolvers to computational denial of service attacks by adversaries deploying specially >> crafted zones with many intentionally colliding key tags [KEYTRAP]. > > I don't see why this is a problem that needs to be solved. I did a > survey of the names in all the large gTLD zones and I never found more > than a single collision per delegated zone. Resolvers can stop after, > say, three collisions with a negligible chance of losing real DNS > data. (Zones built with deliberate collisions don't count.) This is > just one more implementation limit that started with the CNAME limit > suggested in 1035. > > I suppose we can suggest that people adjust their key generation > systems to check the old and new keys, and regnerate the new key if > there's a collision, but that is a minor and not very important tweak. > > R's, > John > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-leave@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [DNSOP] New draft on collision free key tags in D… Shumon Huque
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Hoffman
- [DNSOP] Re: [Ext] New draft on collision free key… Yorgos Thessalonikefs
- [DNSOP] Re: [Ext] New draft on collision free key… Shumon Huque
- [DNSOP] Re: [Ext] New draft on collision free key… Yorgos Thessalonikefs
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Wouters
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Wouters
- [DNSOP] Re: [Ext] New draft on collision free key… Yorgos Thessalonikefs
- [DNSOP] Re: [Ext] New draft on collision free key… Shumon Huque
- [DNSOP] Re: [Ext] New draft on collision free key… John Levine
- [DNSOP] Re: [Ext] New draft on collision free key… John R Levine
- [DNSOP] Re: [Ext] New draft on collision free key… John Levine
- [DNSOP] Re: New draft on collision free key tags … Edward Lewis
- [DNSOP] Re: [Ext] New draft on collision free key… Edward Lewis
- [DNSOP] Re: [Ext] New draft on collision free key… Mark Andrews
- [DNSOP] Re: [Ext] New draft on collision free key… Mark Andrews
- [DNSOP] Re: [Ext] New draft on collision free key… John R. Levine
- [DNSOP] Re: [Ext] New draft on collision free key… Olafur Gudmundsson
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Wouters
- [DNSOP] Re: New draft on collision free key tags … Vladimír Čunát
- [DNSOP] Re: New draft on collision free key tags … libor.peltan
- [DNSOP] Re: New draft on collision free key tags … Petr Špaček
- [DNSOP] Re: New draft on collision free key tags … Vladimír Čunát
- [DNSOP] Re: New draft on collision free key tags … Vladimír Čunát
- [DNSOP] Re: New draft on collision free key tags … Petr Špaček
- [DNSOP] Re: New draft on collision free key tags … Paul Wouters
- [DNSOP] Re: New draft on collision free key tags … libor.peltan
- [DNSOP] Re: New draft on collision free key tags … Peter Thomassen