On Fri, Feb 27, 2026 at 08:26:45PM +0900, Kazunori Fujiwara wrote: > Hello, Mukund san, > > Thank you. The verification speed of existing RSA depends on e being > small (65537), but there is no limit to using a large e. > > I'll think about adding some text as well, > and I'd appreciate any additional text you can suggest.
Fujiwara san, I've prepared the following text as you instructed. Please
feel free to modify it as you please. xml2rfc format is attached to this
email.
M. Limit RSA public exponent
DNSSEC algorithms RSASHA256 and RSASHA512 [RFC5702] use the PKCS #1
RSASSA-PKCS1-v1_5 signature scheme [RFC8017]. The RSA key used in
these algorithms can have variable modulus ("n") and public exponent
("e") sizes. [RFC5702] limits the modulus size for use in DNSSEC,
but the public exponent size is not limited and can be up to (n - 1).
The largest public exponent can cause signature verification to
consume orders of magnitude larger time than the smallest public
exponent.
It is RECOMMENDED that to be performant, DNSSEC implementations limit
the size of the RSA public exponent ("e") that they use in public key
operations according to published current recommendations of
standards bodies of their country or elsewhere. As an example, when
this document was being prepared, [FIPS186-5] imposed a limit of 2^16
< e < 2^256.
DNSSEC signers SHOULD use the smallest value of the RSA public
exponent that is at least 65537. Small public exponents chosen by
the signer would improve signature verification times at the DNSSEC
validator. Fermat primes of the form (2^(2^n) + 1) are typically
used for their structure, however 65537 is the largest known. As an
example, when this document was being prepared, 65537 was the lowest
permitted RSA public exponent in [FIPS186-5]. It is normally
sufficient to let the current version of the cryptography library
(used by the DNSSEC signer) to use its default RSA public exponent
value during key generation.
RSA public exponent values lower than 65537 SHOULD be avoided as they
improve the chances of Bleichenbacher-type signature forgery attacks
in RSA signature verification code that is not written robustly;
although the attack was described in 2006 [Finney-RSA-Forgery-2006],
some implementations were shown to be vulnerable even in 2019
[Chau-BHUSA-2019-RSA-Forgery-WP]. Currently, some zone operators
including some TLD operators use e=3. It is RECOMMENDED that they
use at least e=65537 if they continue to use the RSASHA256 and
RSASHA512 DNSSEC algorithms.
DNSSEC validators SHOULD check RSA public exponent values in keys
that they use in RSA signature verification against an upper limit.
It is RECOMMENDED that implementations especially check RSA public
keys that are read over the wire in DNSKEY RRs when validating a
trust chain, and not rely on the cryptography library used by the
DNSSEC signer to limit it. As an example, when this document was
being prepared, the RSA public exponent was limited to a maximum of
2^256 by [FIPS186-5]. It is RECOMMENDED that DNSSEC validators
accept a range of RSA public exponents upto a small number of bits,
and not a single fixed exponent such as 65537 only.
As an example the following table illustrates the effect of the size
of the RSA public exponent on the time taken for DNSSEC validation of
4096 RRsets:
+=================================+=========+===============+
| CPU (single core/thread) | e=65537 | log_2(e)=3072 |
+=================================+=========+===============+
| Intel(R) Core(TM) Ultra 9 275HX | 0.356s | 31.275s |
+---------------------------------+---------+---------------+
| ARM Cortex-A76 (Raspberry Pi 5) | 2.498s | 311.289s |
+---------------------------------+---------+---------------+
Table 1
Note that PKCS #1 [RFC8017] has other requirements of the RSA public
exponent ("e") such as that it be co-prime with lcm(p-1,q-1).
N. References
N.1. Normative references
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
DOI 10.17487/RFC5702, October 2009,
<https://www.rfc-editor.org/info/rfc5702>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
N.2. Informative references
[Chau-BHUSA-2019-RSA-Forgery-WP]
Chau, S. Y., "A Decade After Bleichenbacher '06, RSA
Signature Forgery Still Works", White Paper, Black Hat USA
2019., 2019, <https://i.blackhat.com/USA-19/Wednesday/us-
19-Chau-A-Decade-After-Bleichenbacher-06-RSA-Signature-
Forgery-Still-Works-wp.pdf>.
[Finney-RSA-Forgery-2006]
Finney, H., "Bleichenbacher's RSA signature forgery based
on implementation error", Email to the OpenPGP mailing
list (archived by IETF Mail Archive)., 27 August 2006,
<https://mailarchive.ietf.org/arch/msg/
openpgp/5rnE9ZRN1AokBVj3VqblGlP63QE/>. Message-ID:
<[email protected]>
[FIPS186-5]
NIST, "Digital Signature Standard (DSS)", FIPS 186-5, 3
February 2023, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-5.pdf>.
[HAC] Menezes, A. J., van Oorschot, P. C., and S. A. Vanstone,
"Handbook of Applied Cryptography", CRC Press.,
ISBN 978-0-8493-8523-0, 1996,
<https://cacr.uwaterloo.ca/hac/>.
Mukund
fujiwara.xml
Description: XML document
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
