IETF Logo Mail Archive

Re: [DNSOP] [Ext] About key tags

Peter Thomassen <peter@desec.io> Sat, 02 March 2024 20:59 UTC

Return-Path: <peter@desec.io>
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 4A55AC14F6AF for <dnsop@ietfa.amsl.com>; Sat, 2 Mar 2024 12:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (2048-bit key) header.d=a4a.de
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 mtmgkUwGAFR0 for <dnsop@ietfa.amsl.com>; Sat, 2 Mar 2024 12:59:07 -0800 (PST)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C011EC14F5E8 for <dnsop@ietf.org>; Sat, 2 Mar 2024 12:59:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Na+20UOD72NPgPbdpezIHNd9J9skwcWH+Ck41FIfAQU=; b=HY38kJNiZrdGmcf6oWKNr+Iz8b yVlun++XC6XL+1fT8rk/58DR6oqwYwPkibuJswMypXoIkpshq9IIFrP5T8S4odrUIASlE30sjqrT6 I/6XxpitGDGRCXHsliZNW6MM3qSEgHaBOHHLg+EO8RMESaLrkApcWcwjcprnFE/iFN2jorBOpU11M vVXK7Js0RzzaK/kE7ZCuq1qB0IUdaCHaT2dV/q6Fyru14tlf3xn6Gp+tfl0OPYgQpDqvZadUe8Nnj KuHttYWMCrqWerIaKb3NqlVc4xZUzxximnQPusMOkbRC16lpacBtKEBlhKbfG0pcIjuaRsN3E5xrR QVMoZJ9w==;
Received: from 208-196.icannmeeting.org ([199.91.196.208] helo=[10.196.197.55]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1rgWRh-00Go7L-15; Sat, 02 Mar 2024 21:59:01 +0100
Message-ID: <8e618813-346c-4abd-ac3c-8196445ea719@desec.io>
Date: Sat, 02 Mar 2024 16:58:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Paul Wouters <paul@nohats.ca>, Edward Lewis <edward.lewis@icann.org>
Cc: John Levine <johnl@taugh.com>, dnsop@ietf.org
References: <4F386814-7ED3-47D3-81C1-1E575FD3C686@icann.org> <741B4E2D-C869-48B7-BD27-5EDC4E1877C1@nohats.ca>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <741B4E2D-C869-48B7-BD27-5EDC4E1877C1@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YDrwmVEE--IpvrX7tIi4-45_7nM>
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: Sat, 02 Mar 2024 20:59:12 -0000


On 2/29/24 18:06, Paul Wouters wrote:
>>  (If no action is taken, malicious activity might follow now that it is described, but I have not heard of a historical case of it.) 
> 
> This attack was more or less described five year ago: https://essay.utwente.nl/78777/ <https://essay.utwente.nl/78777/>
> 
> They didn’t get to the same amplification levels but if attackers had been interested, they could have picked it up as a tool to improve. scripts to run were attached to the paper.

My take is that with the current mitigations (tolerate a very small but nonzero number of keytag collisions), it's unlikely that this will be exploited in any significant way, as the attacker's gain is very limited.

As has been pointed out, no such attacks have been observed in the wild, although another flavor of it has been known for years.

Let's not assume there's a big problem unless there actually is an indication of it. Perhaps we can leave things as they are (with current mitigations), and only once we find that's not enough, with attacks happening and causing much resource usage, then revisit. There's no need to do this now.

> But also, a resolver that sees a higher than normal load could temporarily take certain actions like sacrificing zones with key tag collisions. It doesn’t mean it ALWAYS has to do it.

Exactly.

Peter

-- 
https://desec.io/

v2.23.0 | Report a Bug | By Email