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

Tony Finch <dot@dotat.at> Thu, 24 March 2022 10:50 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 D9D2C3A1936 for <dnsop@ietfa.amsl.com>; Thu, 24 Mar 2022 03:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 57lSKO9vV7Td for <dnsop@ietfa.amsl.com>; Thu, 24 Mar 2022 03:50:08 -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 D33C63A1931 for <dnsop@ietf.org>; Thu, 24 Mar 2022 03:50:08 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0BAE83201DFB; Thu, 24 Mar 2022 06:50:05 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 24 Mar 2022 06:50:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-id: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=+ft/xU xg/EXncYW+ZFRYwM2B1lPyhN0WLvz5cYtm8XE=; b=QWXoT3M6nTDifAfEEpn3TA FMzTi7KsUCxKnMw9YxCKcOmDX0LZNHs5DIXkyqolXOrO8YE+Qr3VJCpqTrLJ9B43 nwUWRYsfuM0Nge8dqq6b4e5CUUIQJ2LEguiXEvDxiPGNGIkJZqeyBG+t/4R4Ubn+ dB29z0TkkJHmQR/tDna9qvRMtVct5Re60OevxGMLAfufd3EK7PIiunkHS2CY27s8 NlAtgjIflNwmwCupiU6g/VkZvgq+LLFC7MVWrC/Ry9Aas8WWtp7sTJoZEwoTo5+F +b1K/kJobpvPrRsdiiEZqP6ruc5aM3Rkhh5PGEHvgRRTRxRsJXMaGqNfX5IdzliQ ==
X-ME-Sender: <xms:3Uw8Yt6XCUufSoIIttYIVR-_N3cI0nrO5LRjZWnGF-bTxADzOs-vqg> <xme:3Uw8Yq45JV6cLneVo9Qz31wcqf6zoh9CgrgWyRT7Il61bV9MTnDDRktuaN7CM9QiX Vf9t4r4PCDVRAk>
X-ME-Received: <xmr:3Uw8Ykc7dI8FAhNjBaI8s-WT2AgcPzZKX4-OjcGBsY1ddJ4yV1HUEyUQlZbZeedlsCb3hFYOnP-AJxyjmXzvsRs6ybFwHw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegledgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffujgfkfhggtgesmhdtreihtddtjeenucfhrhhomhepvfhonhihucfh ihhntghhuceoughothesughothgrthdrrghtqeenucggtffrrghtthgvrhhnpeeihfegge ekudfhfeehvedvheevfedtheeufeegtdeitddtudeuvddvtdeuteekleenucffohhmrghi nhepihgvthhfrdhorhhgpdgtrghmrdgrtgdruhhkpdgrphhnihgtrdhnvghtpdguohhtrg htrdgrthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm peguohhtseguohhtrghtrdgrth
X-ME-Proxy: <xmx:3Uw8YmJzFv66hNMw9ZC9v_KTFTrCrpfBkj4s2l3g0BSywV_Tq812sQ> <xmx:3Uw8YhLx1PHEz6Tm2Cr--T6LzC3zfsGWnn32jmOUl4Ol2c9cWl0sTQ> <xmx:3Uw8Yvxsv6GrUzKLcYjIvEHeUrNrQ73S5WE4Q_NvWNZzBAecoeJhSg> <xmx:3Uw8YvjID1k2Hml2f9Q4nS54Iw_FCMwirkFmVJNcpVytaWrqPGu2zg>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Mar 2022 06:50:04 -0400 (EDT)
Date: Thu, 24 Mar 2022 11:50:00 +0100
From: Tony Finch <dot@dotat.at>
To: Matthew Pounsett <matt@conundrum.com>
cc: Petr Menšík <pemensik@redhat.com>, Paul Hoffman <paul.hoffman@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <CAAiTEH_U_3USjN+Y5t6i=BvPL0w3JmzLfz-LELQXUk1TzDLdpg@mail.gmail.com>
Message-ID: <225a040-ed56-42a6-a8e-f32968865d9@dotat.at>
References: <d383a88c-46cc-8252-3670-b30f68acdf44@redhat.com> <f45a40c7-f265-8e39-963b-2f6434afa18c@redhat.com> <40D559B1-174A-44AE-BAE0-6A0F41D6BFD9@icann.org> <c1c4f10f-0b9e-b390-904b-5b5643d5a650@redhat.com> <7307908B-4BA8-44B7-BDC5-92356FE1CDF5@icann.org> <adfc00af-a934-42cc-df5a-cebe3fce1167@redhat.com> <CAAiTEH_U_3USjN+Y5t6i=BvPL0w3JmzLfz-LELQXUk1TzDLdpg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-1504020720-1648117828=:75179"
Content-ID: <6bd8be8e-e656-a31d-563f-b160b26fee58@cb4.eu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8kAGl_OpVScvZsR-aYMNcs6S46A>
Subject: Re: [DNSOP] [Ext] 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:50:14 -0000

Matthew Pounsett <matt@conundrum.com> wrote:
> On Wed, Mar 23, 2022 at 3:20 PM Petr Menšík <pemensik@redhat.com> wrote:
> >
> > Yes, it says so. It also says SHA-1 is not recommended for new
> > signatures and ietf.org signature was made at 20220318000627.
>
> It's more accurate to say that it's not recommended for new
> deployments.  Operators are encouraged to migrate to more secure
> algorithms, but given an existing deployment there's no MUST
> associated with that migration, yet.

That was a serious error in RFC 8624, that should have been called out
when it was being prepared. Arguably, the same could be said for its
predecessor RFC 6944.

The lifetime of the signature is not relevant for the kind of collission
attack demonstrated by the "SHA-1 is a shambles" paper, because the
structure of an attack is:

  * attacker predicts the the framing in the signature chosen by the
    victim, things like the inception and expiration times

  * attacker generates colliding plaintexts, superficially benign (to be
    signed by the victim) and malicious; this takes some time

  * attacker submits a DNS update containing the superficially benign
    RRset, which is signed by the victim

  * attacker re-attaches the signature to the malicious RRset and uses it
    in a DNS record substitution attack.

This is the same structure as previous successful attacks on X.509
certificates with MD5 signatures. As well as continuing to use a weak
hash function, DNSSEC has not adopted any mitigations, such as
hard-to-predict framing, that are used in the PKIX world.

I have explained how DNSSEC is vulnerable to SHA-1 collisions in detail,
but sadly I was not gentle enough about the way I said it, and various
people on this list got upset and accused me of trying to break the DNS.
Sheesh.

Anyway, I-D version:

https://datatracker.ietf.org/doc/html/draft-fanf-dnsop-sha-ll-not-00

Blog version:

https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html
https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html

Also republished at:

https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/

-- 
Tony Finch  <dot@dotat.at>  https://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: East or
northeast, becoming variable for a time, 2 to 4. In west, slight or
moderate becoming slight later, in east smooth or slight. Fair. Good,
occasionally moderate.