Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

Petr Špaček <> Mon, 29 November 2021 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 783283A0038 for <>; Mon, 29 Nov 2021 09:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Status: No, score=-3.951 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, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=g8pH4H2m; dkim=pass (1024-bit key) header.b=Ok+PA7Ax
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kk6zgadTEF04 for <>; Mon, 29 Nov 2021 09:41:02 -0800 (PST)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CED1D3A0035 for <>; Mon, 29 Nov 2021 09:41:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 05A00435245 for <>; Mon, 29 Nov 2021 17:41:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1638207661; bh=EsiPCxzhf6XJb3/9iYRnI9YsPBRxyWSGiB+bfi2P/tw=; h=Date:Subject:To:References:From:In-Reply-To; b=g8pH4H2mwhMtoC/YxkKW9Zpd9TNaaxkewAtpBgzXwenEOwo7eWYkqhYJpFlYtsTTP kJTEPnGh2GY9regyF8VYn97YGbmvfVUn7fgxfc5W7uevmgifgMQz69XTDcdUhtYynH nSjMxakS+J95MQtU2uC0I9cKR/EOk/ekXMZo++Wg=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id F103BF24315 for <>; Mon, 29 Nov 2021 17:41:00 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id CA68DF24317 for <>; Mon, 29 Nov 2021 17:41:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 CA68DF24317
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1638207660; bh=upOVTFgnyX2bFBXR+G6DO4LSZHNXh2QtUAp8f9Wd4ds=; h=Message-ID:Date:MIME-Version:To:From; b=Ok+PA7AxswF5kxQv2Cu9ZQEP9X4ZOibBsq5v9lSeaDuDhVr3eAGeImOamPc9FHtsL L948gr9Deg/WCH45lyO7Z/j3GWZ4yb62LFieoQo6ML4PbwwzIkzA75zuLsoLDnm9/i QsgfBsAYKLx2/FWJKussFWN1dbnS5+YMGzOWyqz4=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id Fs8TRx-7PoJO for <>; Mon, 29 Nov 2021 17:41:00 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 5B913F24315 for <>; Mon, 29 Nov 2021 17:41:00 +0000 (UTC)
Message-ID: <>
Date: Mon, 29 Nov 2021 18:40:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
References: <> <> <> <> <> <> <>
From: Petr Špaček <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Nov 2021 17:41:08 -0000

On 27. 11. 21 7:12, Viktor Dukhovni wrote:
> On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:
>> Also, when we are theorizing, we can also consider that resalting
>> thwarts simple correlation: After a resalt attacker cannot tell if a set
>> of names has changed or not. With a constant salt attacker can detect
>> new and removed names by their hash. (I'm not sure it is useful
>> information without cracking the hashes.)
> Actually, no.  If one has previously been mostly successful at cracking
> extant names in a zone, rehashing of a small set (much smaller than the
> full dictionary one use) of known names is rather quick.  So old names
> can be quickly identified even after a salt change.  Leaving just the
> hashes of new names.

To be clear: I was talking about attacker who does not cracked the zone. 
You are right that rehashing know names is very cheap.

> Mind you, for cracking the new names, one would still rehash the entire
> dictionary when the salt changes, the number of new names to check is
> not a scaling factor in the cost.  Just a table join.
> So periodic resalting does raise the cost of ongoing tracking of a
> zone's content, if that's the sort of thing one cares enough about.
> Rarely worth it, but mostly harmless if the salt is not too long and
> rotated say on each ZSK rollover.

Plus all the mess with large zone transfers, which often can cause 
issues, especially when done in huge batches (like rotating ZSK/salt 
shared for 100 000 zones on a shared hosting.)

Petr Špaček