IETF Logo Mail Archive

Re: [DNSOP] Fwd: DNSSEC algorithm used on ietf.org

Tony Finch <dot@dotat.at> Thu, 24 March 2022 10:58 UTC

Return-Path: <dot@dotat.at>
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 9063F3A1950 for <dnsop@ietfa.amsl.com>; Thu, 24 Mar 2022 03:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPjj5wlCOqLI for <dnsop@ietfa.amsl.com>; Thu, 24 Mar 2022 03:58:19 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9913A1941 for <dnsop@ietf.org>; Thu, 24 Mar 2022 03:58:18 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4792E3200929; Thu, 24 Mar 2022 06:58:16 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 24 Mar 2022 06:58:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ebdKsgGmdBuiNFxwR qFi54r3xG/xZzNEWlEEFOCcD8A=; b=nKPndR9AU4EGflLVtHNoYVsvAkLmAi/dC kZigZ9EvStQUYo44Ppxz4SakZiMmMeHmLHSL8dTKP92VLINY9kywfm/AzpNMyqR/ GcGgKx05pGG8HJnP9B0d88+KgIfRwrGRRoRR6aZz1EMbt99EDcmxJl1DTcuqOOU1 RvxcxlRRO4w5dfUDDSOFa+TiDsobr9+mknfQ5SS8A1+Jp+OwEXHOjNXNasiZ7aD6 0lUeOyICgDV2oRQSTWecZw2Vw0mbnYj5mjuw76OsYqkLKYtx7+q00hnA9SAz5zSi aEcjdFSl83ac1gg60CJUUsv1MXK+nkd6oidID142XzKRfAnrdtzDQ==
X-ME-Sender: <xms:xk48Yup0uP5IRDCUwk3nKqvNrwmzVlrm_wpon-ums57JVDyIHD3EHA> <xme:xk48YsofQikjWVcvRwho6WTjk4qLWvX8gEjeplr9a2jw7WE8ciTdr587CtQ88Jzny vmr6e0gVknjYYA>
X-ME-Received: <xmr:xk48YjNdT2vI3N3hfrZ2IfN5P66dLTOr5QuuFKCIhslrWiydEE0Kh66v3UoicYxcmg5l3LJP-_i4E1q3E-uailT9f0jXLw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegledgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffujgfkfhggtgesmhdtreihtddtjeenucfhrhhomhepvfhonhihucfh ihhntghhuceoughothesughothgrthdrrghtqeenucggtffrrghtthgvrhhnpeeffeejke dvkeeuiedvieelteeiieejveeugeevheejheevkeejlefhffetveehvdenucffohhmrghi nhepihgvthhfrdhorhhgpdguohhtrghtrdgrthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeguohhtseguohhtrghtrdgrth
X-ME-Proxy: <xmx:xk48Yt7sbWiI48pZ_LJNq79ty7szlY3uLbBZv-JQAlsHcXtVsVsf9w> <xmx:xk48Yt4SiVb2s6lMmBTD8KgCvdlXQjgFMBiVf1GstSsJAuJMLIkxPw> <xmx:xk48YtgY32iDjmXQEJA4VX2GH8yh-zbbHlhyIXYa8Pddf0DLS2Ag-A> <xmx:xk48YqjNyW0oPWyFg9kdzqr-GMMVRuSCRn_i8qXwzYlKqdznhPyuOw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Mar 2022 06:58:13 -0400 (EDT)
Date: Thu, 24 Mar 2022 11:58:11 +0100
From: Tony Finch <dot@dotat.at>
To: Petr Menšík <pemensik@redhat.com>
cc: Brian Dickson <brian.peter.dickson@gmail.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <c345adab-1279-1f90-ba7b-80c9a76b26d0@redhat.com>
Message-ID: <47e3f833-d26b-673d-4325-cb2a7b6f47d2@dotat.at>
References: <f45a40c7-f265-8e39-963b-2f6434afa18c@redhat.com> <42A9E3A3-B19C-4E81-AAB6-E34F352C4889@nohats.ca> <899b43b9-968b-a891-ffe4-461565e8b044@redhat.com> <CAH1iCiqYNG=ZzkMJdeAWw9P8ABCCQUsv3KFC1Ww3JnqstqOgOg@mail.gmail.com> <c345adab-1279-1f90-ba7b-80c9a76b26d0@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-885448552-1648119494=:75179"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/t0_EfeF4_EwwWLCDoIt2d1w_n8k>
Subject: Re: [DNSOP] Fwd: DNSSEC algorithm used on ietf.org
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 24 Mar 2022 10:58:24 -0000

Petr Menšík <pemensik@redhat.com> wrote:
>
> I thought it is not a problem, because it contains multiple iterations.
> Yet popular TLD has iterations==0. This is about how hash of name is
> created from original Next Hashed Owner Name. No other algorithm for
> this is defined.
>
> My conclusion is owner name hash is not security sensitive. But I never
> saw that written in and RFC I read. I cannot say I read or know all
> relevant drafts. Is it obvious to everyone but me?

Maybe not obvious, but it is sort of implied by RFC 5155, because if you
are not worried about zone enumeration then there's no point in heavy
hashing. And since then there has been plenty of academic work showing
how easy it is to enumerate a zone despite NSEC3. There is a fairly
straightforward discussion of the issue in section 2.3 of this draft:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance

-- 
Tony Finch  <dot@dotat.at>  https://dotat.at/
Fisher: West or southwest 2 to 4, occasionally 5 later. Smooth or
slight. Mainly fair. Moderate or good, occasionally poor.

v2.23.0 | Report a Bug | By Email