[DNSOP] Questions before adopting must-not-sha1

Paul Hoffman <paul.hoffman@icann.org> Tue, 30 April 2024 23:50 UTC

Return-Path: <paul.hoffman@icann.org>
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 DF7D9C1654EF for <dnsop@ietfa.amsl.com>; Tue, 30 Apr 2024 16:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 L6TrsFkFDI5b for <dnsop@ietfa.amsl.com>; Tue, 30 Apr 2024 16:50:31 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B328AC15109C for <dnsop@ietf.org>; Tue, 30 Apr 2024 16:50:31 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 43UNoUmt022467 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Apr 2024 23:50:30 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Tue, 30 Apr 2024 16:50:29 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1258.028; Tue, 30 Apr 2024 16:50:29 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Wes Hardaker <wjhns1@hardakers.net>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: Questions before adopting must-not-sha1
Thread-Index: AQHam1kuOpRD9FZLmUGVFKgMTRwPew==
Date: Tue, 30 Apr 2024 23:50:29 +0000
Message-ID: <0334D9C1-F066-460A-893B-C4075FD0BE07@icann.org>
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>
In-Reply-To: <ybl34r2jv3n.fsf@wd.hardakers.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <283C577283F95A438E6EAEB33D3B3ABC@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-04-30_15,2024-04-30_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AfzRXQ6Uf1wei9-idKNObtYvSKk>
Subject: [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: Tue, 30 Apr 2024 23:50:38 -0000

On Apr 30, 2024, at 16:20, Wes Hardaker <wjhns1@hardakers.net> wrote:
> 3. The whole discussion, IMHO, is side-stepping the real issue: if not
> now, then when?  IE, do we never put something at MUST NOT?  Is there a
> usage threshold?  Is it "must be zero"?  Is it "known to be broken and
> everyone must have a flag day instead of a slower process"?
> 
> These are not easy questions, and there does seem to be many different
> opinions.  RedHat led the pack(ish), and maybe Paul and others will be
> the tail end at some very late value.  There is no right or wrong, and
> the line of people are likely to spread out along the timeline.

Thank you for asking the question about questions. But, please, don't simplify with the phrase "MUST NOT" given that the draft has that for two different parts of the DNS: signers and resolvers.

My personal feeling is that "MUST NOT sign because RedHat" is an unfortunate position for us to be in, but one that is defensible. "MUST NOT validate because of some security issue that might never happen" is not defensible, at least to me. The argument "you signing something that we know many resolvers cannot validate is actively bad for security" is defensible.

Until someone can show that a reduction in collision resistance can lead to a reduction in real-world security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason for this group to say to a zone operator who signed their zone in good faith "we are now making your zone insecure"; it's even worse for us to say to zone owners "we're forcing you to pick a different TLD if you still want to be secure".

And, to be clear: I don't support waiting for a usage threshold for "MUST NOT validate". If there is any noticeable chance that an attacker can create a key or signature for a zone they don't control, that is a good enough reason to go to "MUST NOT validate" and let the resolvers decide if they want to be compliant with the new standard. But we aren't there yet, and when we are, the RFC needs to say how we got to that conclusion.

--Paul Hoffman