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

Philip Homburg <pch-dnsop-5@u-1.phicoh.com> Wed, 01 May 2024 05:33 UTC

Return-Path: <pch-b538D2F77@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 BA241C14F6B9 for <dnsop@ietfa.amsl.com>; Tue, 30 Apr 2024 22:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 8LuSoF3IExGR for <dnsop@ietfa.amsl.com>; Tue, 30 Apr 2024 22:33:02 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B5CC14F6B7 for <dnsop@ietf.org>; Tue, 30 Apr 2024 22:33:00 -0700 (PDT)
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-RSA-CHACHA20-POLY1305) (Smail #158) id m1s22aP-0000LfC; Wed, 1 May 2024 07:32:57 +0200
Message-Id: <m1s22aP-0000LfC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Paul Wouters <paul@nohats.ca>
From: Philip Homburg <pch-dnsop-5@u-1.phicoh.com>
Sender: pch-b538D2F77@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> <dc4d8c3c-4de8-fe97-4644-36feb7dffdad@nohats.ca>
In-reply-to: Your message of "Tue, 30 Apr 2024 20:01:18 -0400 (EDT) ." <dc4d8c3c-4de8-fe97-4644-36feb7dffdad@nohats.ca>
Date: Wed, 01 May 2024 07:32:57 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YfDqCVJie89m6rN00DpgvKjaopw>
Subject: Re: [DNSOP] Questions before adopting must-not-sha1
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: Wed, 01 May 2024 05:33:07 -0000

>Their zone is already made insecure by a number of OS/DNS implementation
>combos. Perhaps someone with RIPE Atlas credits can run a check like the
>equivalent of "dig dnskey nic.kpn +dnssec" to see how many endusers
>already get insecure answers for this?

This reads as Redhat strong-arming the IETF into adopting a draft that has
no technical merit. The number of OS/DNS comboes that you refer to are all
from or related to Redhat.

Redhat decided to start shipping DNSSEC validators that violate the current
standard. The existance of such software should not override technical
considerations.

This needs to stay what it currently is, a draft, until there are clear
technical reasons why the security of the internet improves by instructing
validators to not support signing algorithms that include SHA1.

The security of the internet does not improve with the current draft.
Operators likely understand that Redhat systems are not a good basis for
DNSSEC and need to be avoided. To the extent that they don't, we an can make
tools that show that their current validator does not conform to IETF
standards.