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

jabley@strandkip.nl Wed, 01 May 2024 07:34 UTC

Return-Path: <jabley@strandkip.nl>
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 5C14DC14F71A for <dnsop@ietfa.amsl.com>; Wed, 1 May 2024 00:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.794
X-Spam-Level:
X-Spam-Status: No, score=-2.794 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
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 EaAvBfucwoZB for <dnsop@ietfa.amsl.com>; Wed, 1 May 2024 00:34:30 -0700 (PDT)
Received: from qs51p00im-qukt01071901.me.com (qs51p00im-qukt01071901.me.com [17.57.155.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D0AC14F5F1 for <dnsop@ietf.org>; Wed, 1 May 2024 00:34:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; t=1714548869; bh=CN2HuhH5QV8z+aQEpwgppvik7yHrP5YDhI7fE653YEM=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=UEhTRuLUeCnTIto7HXeRz8hVQVZuhL2vbRE4n0d/1QyfqEhw6sQ6t3h39QzVucccq YAUIA9ehbNIdPL8sVlQBxmuFSjHfI5yneQyk4WuGrkygUFpyRfOdE+oiJM05q3208k XMUCNSbg/+c6cQCqxZmegmJs4QoINkFEhlfvDoWV4VpKR1YiCzIl6eTGfqL8pe0hhh /SUvzKJlLYClvuxzdpAbEr2SLwnmZPGxOGDS+j2jyaxWaSbpGgyXvYaStwXtfsi8q1 9OLfznk5M49jLayXQOLgnLCHeDbc/1cDGbYqmSa7oyfhVuycenyJRfq+vP76tIA4Os n9G7BiZslfEPA==
Received: from smtpclient.apple (qs51p00im-dlb-asmtp-mailmevip.me.com [17.57.155.28]) by qs51p00im-qukt01071901.me.com (Postfix) with ESMTPSA id 62F6A628019B; Wed, 1 May 2024 07:34:28 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: jabley@strandkip.nl
In-Reply-To: <m1s22aP-0000LfC@stereo.hq.phicoh.net>
Date: Wed, 01 May 2024 09:34:15 +0200
Cc: dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <856DB748-7D07-4FFF-90B6-CB087588A41A@strandkip.nl>
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> <m1s22aP-0000LfC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-dnsop-5@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
X-Proofpoint-ORIG-GUID: -WaOkWDfxu6S_oIGsDO6g7W4V-uYlyIz
X-Proofpoint-GUID: -WaOkWDfxu6S_oIGsDO6g7W4V-uYlyIz
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-05-01_06,2024-04-30_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 clxscore=1030 mlxscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2405010053
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RRMATvTBnqKCpma7RjQ20eBJ0Ho>
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 07:34:35 -0000

On May 1, 2024, at 07:32, Philip Homburg <pch-dnsop-5@u-1.phicoh.com> wrote:

>> 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.

This seems a bit exaggerated. I don't see Red Hat here promoting changes in the DNSSEC standards.

I think it's uncontentious to say that maintaining DNSSEC software on affected platforms has become more complex. Complexity is not an obvious friend of operational security. The platforms concerned are in widespread use. Regardless of whose business decision triggered the situation, it's certainly possible to agree that the situation exists and that it is more likely to get worse over time than better, e.g. as other OS vendors follow suit and SHA-1 support disappears from crypto libraries.

There are other reasons to deprecate SHA-1 in DNSSEC than mathematical concern about the use of that particular digest algorithm in the protocol. Problems with SHA-1 definitively exist in other places, in protocols that are in much more widespread use than DNSSEC. For example, a message that says "stop using SHA-1" might be more effective at fixing TLS implementations than a message that says "stop using SHA-1 unless you are using it in one of the following ways, in which case it's totally fine". From the perspective of DNSSEC, "stop using SHA-1" might be a much more effective message to communicate at the same time that everybody else is saying it than ten years later.

On the other hand, I have not seen any particularly compelling argument that MUST NOTting SHA-1 will cause the sky to fall. A handful of responses signed by people who are not paying attention will stop being validated. Security and not paying attention are usually related, and not in a good way.

I don't think talk about "Red Hat strong-arming the IETF" is very sensible. 


Joe