Re: [DNSOP] [Ext] About key tags

Mark Andrews <marka@isc.org> Tue, 27 February 2024 23:57 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 59EE5C1D61EB for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 15:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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="OLOPAGyF"; dkim=pass (1024-bit key) header.d=isc.org header.b="pGm24cNL"
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 rNJh8puKijVN for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 15:57:35 -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 49F66C151098 for <dnsop@ietf.org>; Tue, 27 Feb 2024 15:57:34 -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 3ACDC3AB13B; Tue, 27 Feb 2024 23:57:33 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 3ACDC3AB13B
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=1709078253; cv=none; b=Fyp8CABN41Bd/mRTnkR3FY+vK0hPl2nXpi7HdBddGs4LUUlrlzFjiOu1DSlwx/mqdPVxUs3UQ9prkIwA3C6Ho1YX3+/bam0zj2PMKTQe64omkyGxmg+Zes72p0zQcxdEJ4IgB5xKiJkOCDNhpW0Ycmq6lAuYL0YDtQNugUxq6k4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1709078253; c=relaxed/relaxed; bh=eI0UMKjmbx3hWpECMl8b6rorVvyFfefTayw75naB2cU=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=WSkK9cL9OXgoHA5SV27Qp+TbGrjgxu/V94lcemTfKg0+xfeI4Iz8IqD8eBqS0lx6vUOjoLDmL5S7Fc7qdXLCGv1MhTc6HgaUi7sT/d/99WjAi8khndte5tyUKipNHjfo0iOaKTc/PhbZ/x4DETlny0PeQjolvLb8HoIouTIT0vU=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 3ACDC3AB13B
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1709078253; bh=FNgAb3Xlm/V/nnrEg7fe6VrRys3jaZZ1BTVzEHJ7EWc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OLOPAGyFMqv0RseoqYviWv/mZ5dFQfNpa0XO8u3Du6ibGzZi8oPCT1iR86yOn1ljI 9aWJ3J/BP9WQEI9w4XYeuzHzlSjnyK/XTcOpBZm98mqRC8ge6bzZfwB/yMP7CQZNw+ 7Ikoq/DoVcP/NyTZZk/pLDu9eZ6jrRO1v0K4zsiw=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 362DE114B6F2; Tue, 27 Feb 2024 23:57:33 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 0EC0D114B6FF; Tue, 27 Feb 2024 23:57:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 0EC0D114B6FF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1709078253; bh=eI0UMKjmbx3hWpECMl8b6rorVvyFfefTayw75naB2cU=; h=Mime-Version:From:Date:Message-Id:To; b=pGm24cNL1ibniOgiotFCsy/NJQKuCjfQdUapSdqxJXF8Hrmxh1oeoEg2y+cBrs4c4 nATGOr3KwLEFls0OkjDoCFOHZb5mqlLTwq2Jr5fb34G5LBtcooIENmbHb8ue7LMKDS 1yW5HdV9VEJ3aDmJWa1eNWe1JPl0q3ZIkOrl6Wug=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id zNfgdjJNJTPn; Tue, 27 Feb 2024 23:57:33 +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 47793114B6F2; Tue, 27 Feb 2024 23:57:32 +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: <a515dbd0-7789-00a2-8249-785fc748e4d4@taugh.com>
Date: Wed, 28 Feb 2024 10:57:18 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B48D20AA-DFD0-412D-A4F3-9FA875F9D979@isc.org>
References: <20240227220905.E06018410007@ary.qy> <447E01C7-C245-4BA3-88C7-AF847B50047A@isc.org> <a515dbd0-7789-00a2-8249-785fc748e4d4@taugh.com>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FnK8nYMqo0ff2bidi-OSAbqNi_8>
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 23:57:39 -0000


> On 28 Feb 2024, at 09:58, John R Levine <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.
>> 
>> If you forbid in the protocol the tools will be fixed to prevent it
>> occurring when signing and the validators don’t have to be prepared
>> to play trial and error when there are duplicate tags in a DNSKEY
>> RRset. ...
> 
> That's all true, but people will publish them anyway, so the tools need to defend against them no matter what the protocol says.  Based on what I've seen, pairs of colliding tags appear innocently, larger numbers don't, so you set the limit in the single digits.
> 
> Is it really so much harder to write code that allows, say, three signatures and three IDs than code that only allows one?  As I hardly need point out, the process cost of changing the protocol is high, and it will take approximately forever for the long tail to notice.

It’s not the complexity of the validator we are worried about.  The number of crypto verifications per second is really low on all hardware.  Being able to stop validating on the first failure rather than having to continue because the attacker has constructed a colliding key tag rrset is beneficial to getting good put trough in the presence of a DoS attack.

As for the long tail we already have vendors that are doing what we are requesting to be formalised for years.  Additionally this is in a component of the system that even if it isn’t updated in unlikely to generate DNSKEY rrsets with collisions.  Most DNSKEY rrset don’t have more than 4 keys at any one time per algorithm.   Also DNSSEC tooling is constantly being improved in terms of additional automation which encourages upgrades for anyone that is signing their zones.  DNS server and with them the associated tooling do get upgraded regularly.  We have the graphs to prove that.  Upgrading software is a regular occurrence.

I would put the time between publication of new signing rules and relying on them when validating at 2-3 years looking at the correction efforts that have already been done in the DNS in the past.

> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

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