[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values-05
Mukund Sivaraman <muks@mukund.org> Sat, 21 February 2026 03:50 UTC
Return-Path: <muks@mukund.org>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 665DCBB0CD29 for <dnsop@mail2.ietf.org>; Fri, 20 Feb 2026 19:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=mukund.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcJtUvyJ0QY0 for <dnsop@mail2.ietf.org>; Fri, 20 Feb 2026 19:50:42 -0800 (PST)
Received: from mx.mukund.org (mx.mukund.org [IPv6:2a01:4f8:13a:28c1:1::d8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3F662BB0CD1D for <dnsop@ietf.org>; Fri, 20 Feb 2026 19:50:42 -0800 (PST)
Date: Sat, 21 Feb 2026 03:50:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1771645834; bh=LCmnKx3Ly7k0m7rJVtIw1N8taXrOSZ6glVzuOlOBPkc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YOycCZiEC/s/i1eIJOD97J/H5Kyzo3C9j8ssLsE2Ef7dg0RPeD6mlCLi5lZiyBrUM ETuMRGg5CzRHDXUexbLtHl79RIX7f9Wt/QFw2Fe2AwK9LNGBZJ9puM5MKHC24Cb73C vwrblFPhcq6bzmzeAKSotV/0i+9K8uKKcVEgD0tNUrm9pIh/jgvFrC/uR9hGAyPmo0 hRpa3JYtCMu5nnIa833+/WIAWOEQ5ch7mrgQ6JCiLW4Eza6/4g7Pt32p+a7Cz4A17b NneU2UuN9IgLNlQEiPSRmSDopNTRRHQ+YAXjxywgA6NK9GeVxalTVIe50Q9PIbt18u s9NbZ2Di3exjg==
From: Mukund Sivaraman <muks@mukund.org>
To: Kazunori Fujiwara <fujiwara@wide.ad.jp>
Message-ID: <aZkrhQm9kUfDk0gC@p5>
References: <20260210.162822.769915785065787587.fujiwara@wide.ad.jp>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="fzNoPz5V2WUAWkFy"
Content-Disposition: inline
In-Reply-To: <20260210.162822.769915785065787587.fujiwara@wide.ad.jp>
Message-ID-Hash: YEWGRBN6QBT6KG666LUT5IG53DWZEG2H
X-Message-ID-Hash: YEWGRBN6QBT6KG666LUT5IG53DWZEG2H
X-MailFrom: muks@mukund.org
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
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values-05
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9-P7opL0Pena0G8_Olrw6GInif8>
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>
Dear Fujiwara san, On Tue, Feb 10, 2026 at 04:28:22PM +0900, Kazunori Fujiwara wrote: > Dear dnsop WG, > > Authors submitted draft-fujiwara-dnsop-dns-upper-limit-values-05. > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-dns-upper-limit-values/ Would you also consider adding a limit on the size of the RSA public exponent "e" in the DNSSEC validation path? There is no low limit on the public exponent in PKCS #1 (it can be up to modulus - 1). While the RSA modulus itself is limited by DNS RFCs 3110 and 5702 to a max of 4096 bits, there is no limit on the public exponent (it can be up to modulus - 1). Having a small RSA public exponent is important for efficient RSA signature validation, otherwise validation performance can be significantly degraded. RFC 3110 recommends that it be small, but this doesn't prevent an attacker from using a high value. FIPS 186-5 and NIST 800-56B specify 2^16 < e < 2^256, but there are several TLDs still using e=3, so the lower limit cannot be 65537. There should be a high limit. Crypto libraries may limit the RSA public exponent. For example, current OpenSSL master HEAD limits it as below in the signature verify path: /* for large moduli, enforce exponent limit */ if (BN_num_bits(rsa->n) > OPENSSL_RSA_SMALL_MODULUS_BITS) { if (BN_num_bits(rsa->e) > OPENSSL_RSA_MAX_PUBEXP_BITS) { ERR_raise(ERR_LIB_RSA, RSA_R_BAD_E_VALUE); return -1; } } where OPENSSL_RSA_SMALL_MODULUS_BITS is 3072, and OPENSSL_RSA_MAX_PUBEXP_BITS is 64. However if the modulus size is 3072 bits, the public exponent is unchecked and can be up to 3072 bits. Some crypto libraries may not limit "e" at all. This may not be an issue in some other applications, but performance of DNSSEC validation at resolvers can be severely affected if it is used unchecked. So, it would be sensible to limit the RSA public exponent size at the application layer (DNSSEC validator). BIND has limited it since at least 2012. Loop derived from BIND and also has had the limit (though the limits were changed in Loop last year as part of OpenSSL 3 rewrite of the crypto code). I am not familiar with other implementations. A sample RSA keypair with a 3072-bit RSA public exponent is attached. It causes validation performance to drop by orders of magnitude if "e" is not checked in the DNSSEC validator linked against OpenSSL. Sample times for verifying 4096 RRsets: +---------------------------------+---------------+----------+ | CPU (single core/thread) | log_2(e)=3072 | e=65537 | +---------------------------------+---------------+----------+ | Intel(R) Core(TM) Ultra 9 275HX | 31.275s | 0.356s | +---------------------------------+---------------+----------+ | ARM Cortex-A76 (Raspberry Pi 5) | 311.289s | 2.498s | +---------------------------------+---------------+----------+ Mukund
- [DNSOP] draft-fujiwara-dnsop-dns-upper-limit-valu… Kazunori Fujiwara
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Mukund Sivaraman
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Petr Špaček
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Philip Homburg
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Petr Špaček
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Philip Homburg
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Kazunori Fujiwara
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Mukund Sivaraman
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Felix Linker
- [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-… Petr Špaček