[DNSOP] Re: Questions before adopting must-not-sha1

Philip Homburg <pch-dnsop-6@u-1.phicoh.com> Wed, 13 November 2024 16:03 UTC

Return-Path: <pch-b6CAFA0C7@u-1.phicoh.com>
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 DB5F5C151533 for <dnsop@ietfa.amsl.com>; Wed, 13 Nov 2024 08:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 mFPMROW-z5u3 for <dnsop@ietfa.amsl.com>; Wed, 13 Nov 2024 08:03:45 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85F4C15109A for <dnsop@ietf.org>; Wed, 13 Nov 2024 08:03:42 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305) (Smail #158) id m1tBFqG-0000LkC; Wed, 13 Nov 2024 17:03:40 +0100
Message-Id: <m1tBFqG-0000LkC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-6@u-1.phicoh.com>
Sender: pch-b6CAFA0C7@u-1.phicoh.com
References: <D95A2D1F-1203-4434-B643-DDFB5C24A161@icann.org> <67B93EF4-6B70-402E-9D78-1A079538CA18@strandkip.nl> <m1s1Wur-0000LDC@stereo.hq.phicoh.net> <f0f9c0ce-2911-9b4c-0d60-47c204add2d4@nohats.ca> <DB9D1C93-95D1-4B76-AD74-4C60433D479A@icann.org> <7dd5f090-b8b7-ea5e-82f2-d622298c7299@nohats.ca> <ybl7cgejxcr.fsf@wd.hardakers.net> <4907A4B7-1EAE-460D-91E8-4F7D292C7302@icann.org> <ybl34r2jv3n.fsf@wd.hardakers.net> <0334D9C1-F066-460A-893B-C4075FD0BE07@icann.org> <0e5914c7-d3fa-443c-8099-1b5bad39a50e@redhat.com>
In-reply-to: Your message of "Wed, 13 Nov 2024 00:34:56 +0100 ." <0e5914c7-d3fa-443c-8099-1b5bad39a50e@redhat.com>
Date: Wed, 13 Nov 2024 17:03:39 +0100
Message-ID-Hash: QL6NPF5FNWN6DUHP24MXHH5VLHVSNY2S
X-Message-ID-Hash: QL6NPF5FNWN6DUHP24MXHH5VLHVSNY2S
X-MailFrom: pch-b6CAFA0C7@u-1.phicoh.com
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: Petr Menšík <pemensik@redhat.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Questions before adopting must-not-sha1
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8pCrfRM9mNC2pbFjscb8xL1PUJk>
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>

>Tony Finch has correctly identified in SHA-1 chosen prefix collisions 
>and DNSSEC [3] article that when a single record is usually safe, 
>multiple records might allow creating fake signature even in DNSSEC. 

There are two types of attacks on hash functions: collisions and second
pre-image attacks. 

There is no practical 2nd pre-image attack for SHA-1, so we can concentrate
on collision attacks. A collision attack requires that the victim to
accepts malcious data from an attacker

There are many, proably even the majority of DNSSEC signed domains,
where this is not an issue. Attackers cannot influence the contents of a
zone. In those cases, using SHA-1 is secure.

Obviously we need to move away from SHA-1 as fast as possible. But we do
those domains a disservice if we treat them as insecure. In
particular, DANE will stop working if a domain is considered insecure.

We already see the operational impact. People with RedHat systems notice
that DANE suddenly stops working. They have no clue where is coming from,
they just see that unbound doesn't set the AD bit. 

The solution should be that RedHat provides a way to link with a different
crypto library that does support RSASHA1.