Re: [DNSOP] [Ext] DNSSEC Strict Mode
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 26 February 2021 19:20 UTC
Return-Path: <ietf-dane@dukhovni.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 D68DE3A1563 for <dnsop@ietfa.amsl.com>; Fri, 26 Feb 2021 11:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfsdDrT_2yWj for <dnsop@ietfa.amsl.com>; Fri, 26 Feb 2021 11:20:39 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 8D3E33A1562 for <dnsop@ietf.org>; Fri, 26 Feb 2021 11:20:39 -0800 (PST)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id BCD7CC23D9 for <dnsop@ietf.org>; Fri, 26 Feb 2021 14:20:38 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CA+nkc8D4aC30ooepVDUewU_rSqh1XaBa2qCgE7izuEBALXczSw@mail.gmail.com>
Date: Fri, 26 Feb 2021 17:20:38 -0200
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <4AFB7838-69EA-4F25-9084-E27141E6015F@dukhovni.org>
References: <CAHbrMsBeCiZ-31hjKvet2UPDPFhdVYpgqR6Kw-WWz1ERgeSFoQ@mail.gmail.com> <B2CF080D-7513-4414-9316-9999AF441F43@icann.org> <CAHbrMsAdbn85AUCY9Yr6XXU-6Ti4dKwR1=zncGj4z-SjznAF3w@mail.gmail.com> <76A8C023-AB7D-4D50-BE85-B1BAFDD3FBD4@icann.org> <CA+nkc8D4aC30ooepVDUewU_rSqh1XaBa2qCgE7izuEBALXczSw@mail.gmail.com>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IZtZy4YoOjFqQmrPlJqFRpT0W3U>
Subject: Re: [DNSOP] [Ext] DNSSEC Strict Mode
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 26 Feb 2021 19:20:42 -0000
> On Feb 26, 2021, at 1:06 PM, Bob Harold <rharolde@umich.edu> wrote: > > If you sign your zone with several algorithms, and mark them all 'Strict", you are asking my resolver to do extra work. I will probably configure my resolver to only validate with one algorithm. Maybe the strongest, maybe the least cpu intensive, my choice, not yours. In terms of downgrade resistance, that's just fine. The signal should not be interpreted to require the resolver to check them all, or any particular one. Rather, it would indicate that you're free to conclude there's an attack and fail, if your preferred strict algorithm is not included in the set of returned signatures. This is sufficient to protect against downgrades from whatever algorithm you would have chosen if you had them all, to some other one that you would not have chosen. One could also take the view that all the algorithms are equally good, and ignore the signal, though if I saw a promise of P256 + RSA, and got back just a 512-bit RSA signature, I'd be reluctant to conclude that it is as strong as the missing P256 signature... :-) So, in principle the proposal is a fairly natural anti-downgrade mechanism. The main question is whether this is plausibly needed, and here I am not so sure. I'd prefer to instead see more attention to avoiding weak parameters. This looking at SHA-1, we need to: * Phase out DS hash algorithms 1 (and outdated GOST 3) * Phase out DNSKEY algorithms 5 and 7. Looking RSA-base DNSKEY algorithms, the the most widely used RSA key sizes are: # domains key bits --------- -------- 7,972,397 2048 7,342,144 1024 122,529 4096 22,678 1280 13,763 1536 8,273 512 1,502 Other [1] I would therefore propose that we: * Update the RSA-based algorithms to require keys of at least 1024 bits and at most 2048 bits. * After the sunset date, shorter keys are treated the same way as unsupported algorithms (zone is unsigned). * After the sunset date, longer keys are treated as signature verification failure! For better security than RSA-2048, use P256 or Ed25519. * Set a sunset date for KSKs shorter than 1536 bits, after which time KSKs with < 1536 bits are equivalent to unsigned. * Strongly recommend ZSKs of at least 1280 bits, and update defaults in signing tools to be 1280 bits, if currently set to 1024-bits. * Recommend 1280 bits for ZSKs. * Recommend 2048 bits or 1536 bits for KSKs * Require the RSA exponent to be one of the 4 used in the wild that are not outright errors: 2^2^4 + 1 = 0x10001 = 65537 (8,126,993 domains) 2^2^30 + 3 = 0x40000003 = 1073741827 ( 29,398 domains) 2^2^0 + 1 = 3 ( 218 domains) 2^2^5 + 1 = 0x100000001 = 4294967297 ( 21 domains) [ https://stats.dnssec-tools.org/ ] possibly just the first 3, the 21 domains using 2^2^5+1 can migrate to a more sensible exponent. Improving practices in this space will do a lot more to improve DNSSEC security than downgrade-resistant key algorithm signalling. -- Viktor. [1] Full RSA key bit size frequency table: 7972397 2048 7342144 1024 122529 4096 22678 1280 13763 1536 8273 512 345 1028 299 2304 268 2560 124 2024 114 1300 99 3072 72 2047 34 1023 22 1152 17 768 12 1350 12 1550 12 1048 10 2046 4 2014 4 2096 3 4086 3 2044 3 2045 3 1304 3 2112 3 1400 2 4095 1 1475 1 1483 1 1527 1 1530 1 1294 1 1972 1 1984 1 256 1 1292 1 2028 1 2038 1 2043 1 1291 1 1283 1 1248 1 1014 1 2119 1 1155 1 2319 1 2480 1 1080 1 1042 1 3096 1 3968 1 4075 1 4092 1 1336 1 1330 1 1345 1 1315 1 1430 1 1444 1 1455 1 1456
- [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode Petr Špaček
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Samuel Weiler
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Brian Dickson
- Re: [DNSOP] DNSSEC Strict Mode Ralf Weber
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Brian Dickson
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Wes Hardaker
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Joe Abley
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Samuel Weiler
- Re: [DNSOP] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Bob Harold
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Joe Abley
- [DNSOP] Fwd: [Ext] DNSSEC Strict Mode Ulrich Wisser
- [DNSOP] signalling mandatory DNSSEC in the parent… Jim Reid
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ben Schwartz
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Paul Wouters
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Havard Eidnes
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ben Schwartz
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser