[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC

Mark Andrews <marka@isc.org> Sun, 28 July 2024 03:17 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 72395C14F6BE for <dnsop@ietfa.amsl.com>; Sat, 27 Jul 2024 20:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.515
X-Spam-Level:
X-Spam-Status: No, score=-3.515 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, 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="BEPFoJmW"; dkim=pass (1024-bit key) header.d=isc.org header.b="JjVwbdcy"
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 5m0Xs-ez4J_N for <dnsop@ietfa.amsl.com>; Sat, 27 Jul 2024 20:17:13 -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 5E86DC14F610 for <dnsop@ietf.org>; Sat, 27 Jul 2024 20:17:12 -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 DFCD43AB267; Sun, 28 Jul 2024 03:17:11 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org DFCD43AB267
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=1722136631; cv=none; b=X3GOhNwItWzNo+wf8U3KK9+hjngAUrdS3hcrTPeqX3snzqKFw2NogCD2izenfNDFGRDtqFgnWHu3VTplAauc7+gU7+e6ZWUSpJwGXL9mOC6yHZAbPBVM1omOt/VhMWYqZu1vBDoS6cVvmf1QVrhfAtx/N5dAOYeUgrUWREXbPe4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1722136631; c=relaxed/relaxed; bh=HabThYqBc+S6RBcHMETIldoZjcXtv6gOeIHwKCJyw3M=; h=DKIM-Signature:DKIM-Signature:From:Mime-Version:Subject:Date: Message-Id:To; b=OyLDFilJ7hRIYPXXOYRiSmNqtU2qgZENair3DvYLLHY1dCkeVgZ8CwEex95CvQ4d5RfYft6w5fWhFdm70l1deAR2i8wnS26B/zKH9JVF3xmRjV3aCC3LSDNlJLIvsdZvYqP3Xhjv2RDUa62pPhK88J24DxVsAiPUuv94EILRiY8=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org DFCD43AB267
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1722136631; bh=gOrZEqszN8WfZPpGDRVhoM9xzPy8MXV2KxhVMinQIDo=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=BEPFoJmWifD/Cn9Q6eG3q75+5DkCvgCbKJanfbOp8gspO1+rm+t7qTtK4vuJwbuuf pPMV8VCb0z9Tj3ND3rHBSO2o77gZdIKNuOCQCTE+jcoz2f+QQEeTMlHKMdzB63zMEj ggWdnAnkH+r2zYf7GUEmfDYsn17UUN4AFscXeURY=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id DB340A2018C; Sun, 28 Jul 2024 03:17:11 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id B9458A20278; Sun, 28 Jul 2024 03:17:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org B9458A20278
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1722136631; bh=HabThYqBc+S6RBcHMETIldoZjcXtv6gOeIHwKCJyw3M=; h=From:Mime-Version:Date:Message-Id:To; b=JjVwbdcyiRmjNYcPjF0gL2bAV/YONxAMdCicRoWDJt4yv4D+AcjcP3SOno7O7bIke PTR0xyMHwovItQKQLfaezDyFkXI+gUxFM8umDVBfAk8LnieeUIsXRuNNRsFrtpQcUV 33UAW+LG02IivxYEkkZLGmz28Pr8u2T+VqCv/1uY=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id 79PUKFV5sP_9; Sun, 28 Jul 2024 03:17:11 +0000 (UTC)
Received: from smtpclient.apple (unknown [216.9.110.1]) by zimbrang.isc.org (Postfix) with ESMTPSA id A6295A2018C; Sun, 28 Jul 2024 03:17:11 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-8E757E22-19FB-45BA-B35F-67AAF96AD3C2"
Content-Transfer-Encoding: 7bit
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Sat, 27 Jul 2024 20:17:00 -0700
Message-Id: <1328B124-8C15-435A-B2C1-EB44B9B265C7@isc.org>
References: <118eb776-1f8f-4dae-808b-2be09ecbebd9@iecc.com>
In-Reply-To: <118eb776-1f8f-4dae-808b-2be09ecbebd9@iecc.com>
To: John Levine <johnl@iecc.com>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: 2BM4CPRWCOMJ66PK5VECSD3XHYXIXDWZ
X-Message-ID-Hash: 2BM4CPRWCOMJ66PK5VECSD3XHYXIXDWZ
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: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.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/GLySKvn6xGweoGqbuhZ_TM3nGGI>
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>

I suspect that the validator will try a RRSIG/DNSKEY pair and bail out on crypto verification failure.  Alternative it will just bail out before doing any crypto.  Up to the validator. Minimal change will get the first behaviour.  More comprehensive change the second. 
-- 
Mark Andrews

On 27 Jul 2024, at 17:01, John Levine <johnl@iecc.com> wrote:


I am a bad person. My zone uses the new algorithm and I put in two keys with the same tag. Now what? Other than perhaps stopping at two keys rather than three, what is the difference in what resolvers do?

Get https://bluemail.me" rel="nofollow">BlueMail for Android
On Jul 25, 2024, at 19:54, Shumon Huque <shuque@gmail.com> wrote:
On Thu, Jul 25, 2024 at 5:44 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
On Jul 25, 2024, at 17:34, Shumon Huque <shuque@gmail.com> wrote:
>
> Folks,
>
> For discussion ...
>
> Mark Andrews, Elias Heftrig, and I have a new draft on collision free key tags in DNSSEC. This topic has been in the air since the Keytrap vulnerability disclosure -- and IETF120 hallway track conversations this week prompted us to write up a rough initial proposal for this. Will need much more fleshing out of details etc, but we hope this can serve as a starting point ...
>
>     https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00 [http://datatracker.ietf.org" rel="noreferrer nofollow" target="_blank">datatracker.ietf.org]

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].

The main part of the proposed solution is listed as:

DNSKEY algorithms MUST have DNSKEY RRsets that do not have colliding key tags

There is a mismatch here. If the worry is an attacker creating colliding key tags to cause more work, that attacker is simply going to ignore the MUST requirement.

It's a phased mitigation over time.

The actual proposal is initially only "new" DNSKEY algorithms will have the no colliding key tags requirement. In which case, yes, the adversary will just use existing algorithms to deploy their attack. Arguably, currently deployed defenses that limit the number of colliding key tags already deal with this. Over time, we could envision requiring this for existing algorithms too, or moving everyone to the new algorithms. Anyway, there is a diverse solution space - we need the community to discuss the various possibilities and hopefully converge.

The other goal of course is to make validation more efficient, and avoid resolvers having to unnecessarily check signatures for keys that they don't need to.

Shumon.

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-leave@ietf.org