[DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Thu, 16 May 2024 18:32 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 190CDC1840C9 for <dnsop@ietfa.amsl.com>; Thu, 16 May 2024 11:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (1024-bit key) header.d=nic.cz
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 wfQrrlc3yEdY for <dnsop@ietfa.amsl.com>; Thu, 16 May 2024 11:32:40 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 7C669C1840DC for <dnsop@ietf.org>; Thu, 16 May 2024 11:32:39 -0700 (PDT)
Received: from [IPV6:2a02:768:2d1c:226:4208:e1df:460d:4793] (unknown [IPv6:2a02:768:2d1c:226:4208:e1df:460d:4793]) by mail.nic.cz (Postfix) with ESMTPSA id E7D681C06DB for <dnsop@ietf.org>; Thu, 16 May 2024 20:32:36 +0200 (CEST)
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=vladimir.cunat@nic.cz smtp.mailfrom=vladimir.cunat+ietf@nic.cz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1715884357; bh=Ob7HSxrtFIF4TQYfvO4F8fnpY0VTdo5p6fPzCQ6GOSc=; h=Date:Subject:To:References:From:In-Reply-To:From:Reply-To:Subject: To:Cc; b=jbOhFD+CNC0CNibqfRyErO8JeDgcwZgSeKWN9BnevjESI7sMAxWuS8d4MalXCyjq1 SLaI8Fm1hZdzXTbmt9skrpkKpTM5bFm8yog6AKDU7Jip2+/qcUpSY4X2bGK6eWuPBH m/uEwSqFiIDV8VvSHXAzAjy8NenrAqyX0li1yPT4=
Content-Type: multipart/alternative; boundary="------------9AAePJTuvoAYz3KqpZFZneQW"
Message-ID: <bef5df91-fdf3-4a99-8a3d-9c9528b475a8@nic.cz>
Date: Thu, 16 May 2024 20:32:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dnsop <dnsop@ietf.org>
References: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com>
Content-Language: cs, en-US
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Autocrypt: addr=vladimir.cunat@nic.cz; keydata= xsFNBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABzTBWbGFkaW3DrXIg xIx1bsOhdCAod29yaykgPHZsYWRpbWlyLmN1bmF0QG5pYy5jej7CwZQEEwEIAD4CGyMFCRTR 36EFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCYWaw GAAKCRDnR98flXWjqlYyD/9Teb9rKFn+09jnK6JhZi++kA6gCMM2LbsKKJBSvFAYhhAMPpc/ HR0j6okBfCImlca6Fniqe7xyo0nkQq9mvXirGM03c940rcD5ymRqT+TjCW9seXWTccimi9Rc onatDfSwyJMWpzDkT2FQNnNbR5hSRSaI/BJlISGDfIgJeWRtrt7xCyPQd2bzSW/DiVMQDnLz 1crsSjM6SWNgvCuBHNo6C7oBvmgqGYew04uBDragDsa/43wjxHTxxCChDnal8uQ7aIgOXurh wPg6bHgQv4zNo67zviEapxb6+zO/kMn79GW5BXn7CaebY6Iwr+sST7c/wSsIfcMTbVCa2XxS +9Trc+P9GAMIl+M/pJY6KcdIuAC1VDolm+4v9j4j9t5+CZzwHy3ZQpZPQnk5AjrtAgIAb6yo tcP+3hJxqjoE7uDmhnxWjrU47haiktMDnQURkk+Yd6So8aw8TfB4CPmaRdRHzHeqL3y1qTFS MBPXFbnopnKQKn0rm0BAk48J7A0ps3NumqWghy/BWl39qRvSebg3M8XXFM1Vn4G/telnYGxa KifNjtkgsrE3BJKzR/JtkeYu4gmjuVpUBS39hRzgVi3d0Y1dc7QiJr+HYubJMEC8IFtvsItE KMFT4D3N/CQD2u9yDUYWjytyVHMKjRK/SVDX0Rsi/nk8E1+G+WCh3XSfSs7BTQRYA5J2ARAA yHww3huLEtsdyqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zx x85WcuaO1OVqung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPp DkGodS0De9osA+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOo jGMiLoZvELY86Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxM t5LB/MSrmECB5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoR bh7i4fT0lWvMXTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJ V7xVLTtS1EamVqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p 02oSecDl5yVXplJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGX M71OpmONQJGF24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0 Q2zochS64Mcg0YzL1sinWPN1rXLDk3lwpIsAEQEAAcLBgwQYAQgADwUCYWawGAIbDAUJFNHf oQAoCRDnR98flXWjqgkQ50ffH5V1o6oJEOdH3x+VdaOqCRDnR98flXWjqrQYEAC3goVoBxBn v/J8ClqwvAjEMisoiUZUn7xEYuTOND2McCguyB6PnpDHZS3PJFZL+Vkqt80HDaETIx7rWZQl aRiWreT8Igop3uiN2eSXyrFO3yROClzw9I6/ZAsvyB5QlrCi2Uxx9CzpPfLamXBUMBTOZ0BM 7vFLPOgcZWbOSGjdIyCw9qlAvhGHoNIXdJMmvtelDWqPTcQnlBKEsMYbQeCCDAiU1D8dKVhK wh8XglI78T3doeQNdOg0/932vLoTx6/YKB7X63ldLKBrsbta6hqzJ+13KK7BnbfV1+Lcjx3F w1wmTC3nY2E7uznGEOt4YvmVlFyT73CKweErQrpmhRAsC6HaXQ1ge5+jhfK/l//3j240vKrf vgNtCxg+Jewa1sQ3spq56i5ljfEQX9sVeMrVX3EcdXq3BTBojUVLxkofpID+iew+Mk+MRk6v nwrUugR8ljAdJaF3Fr9CJv+s56SKVHL18i+vLOCYqrpLfeKypcG/yAejElmp58ZPFM1nxoBV 3hlK0fGFi7kEqNugHHjTsrtoDFvpPZGItLKpAczD5Nc1mTf4EjaQ8ruwFhqb+EbTioSYWrsf M8LcKqM6ksfqZaZ2M+Yn8AjTLs5zOk9I+JrCkIitTe5SMCgRmk9j/Eif3nGicrnSM+HbNvhl Jen8akkduxILPhFGNAZku8BEqw==
In-Reply-To: <CAHw9_iKavFk6QBU=rYXU5R7EigJZHNqyYengUpPF3KiCiCUEJQ@mail.gmail.com>
X-Virus-Scanned: clamav-milter 0.103.10 at mail
X-Virus-Status: Clean
X-Rspamd-Action: no action
X-Spamd-Bar: ----
X-Rspamd-Server: mail
X-Spamd-Result: default: False [-4.38 / 20.00]; BAYES_HAM(-5.00)[100.00%]; R_MIXED_CHARSET(0.71)[subject]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:44489, ipnet:2a02:768::/32, country:CZ]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[ietf]; TO_DN_ALL(0.00)[]; NEURAL_SPAM(0.00)[0.119]
X-Rspamd-Queue-Id: E7D681C06DB
Message-ID-Hash: R6V4BR45XRX4DTWB6DOC4ACYIU3UGDKU
X-Message-ID-Hash: R6V4BR45XRX4DTWB6DOC4ACYIU3UGDKU
X-MailFrom: vladimir.cunat+ietf@nic.cz
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LMzLxkZnAimF_GWbk-NYgiTpvds>
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>

On 14/05/2024 22.57, Warren Kumari wrote:
> This means that we should actually have a column per type (i.e 
> “Operators” and “Implementers”) crossed with a column per DNSSEC usage 
> type (“Signing” and “Validation”), such that for the “Domain Name 
> System Security (DNSSEC) Algorithm Numbers” table we would be adding 
> FOUR columns:

I'm not happy about splitting it for validation.  I'd rather strive 
towards a shared global expectation on which algorithms get supported by 
validators, instead of standardizing that individual operators can tweak 
this.  (I hope this can be just about SHA1 at this point.)


The arguments have been posted in the recent weeks.  AFAIK validator 
implementations tend to have only two states for algorithms: supported 
and unsupported, as that's what all the DNSSEC RFCs define.  Downgrading 
will make (some) security properties worse than keeping to validate with 
a weak-ish algorithm.  A current example is Fedora/RHEL for SHA1 stuff.

While I recognize that it's not easy for everyone to agree on support 
status (of SHA1) in validators, not agreeing seems worse than either 
result.  In the current RFC 8624, SHA1 signing is "NOT RECOMMENDED".  
With that it seems rather harsh to officially allow some validators to 
downgrade these to insecure.  I'd imagine that first we should 
standardize some stronger discouragement of SHA1 in zones and keep that 
for some time.


I can imagine the signing side split.  For example, saying now that it's 
not that bad for implementations to still allow to be configured with 
SHA1, but strongly discourage zone operators from utilizing that.  Or 
encouraging SW to be able to sign with ed25519, but stating that (a few 
years ago) the support in deployed validators didn't look too great, so 
zone operators should be more careful.

--Vladimir | knot-resolver.cz