]> BWeb-SSL Services UG & Co. KG

Breite 12 Mengen BW 88512 DE ietf@bastian-buck.de https://bweb-ssl.de

General Network Working Group post-quantum cryptography dkim ml-dsa fn-dsa This document discusses suitable post-quantum (PQ) signature algorithms for DomainKeys Identified Mail (DKIM). Because DKIM signatures are carried in emails, and public keys in DNS TXT records the usage of already standardized algorithms is limited. For compatibility reasons, signers that want post-quantum security are expected to add a PQ signature to a message in addition to a traditional signature, using separate DKIM-Signature header fields. The existing RSA and Ed25519 algorithms remain unchanged.

Introduction DomainKeys Identified Mail (DKIM) signs email messages by hashing selected header fields and the message body and signing the resulting header hash with a digital signature. Recipients obtain the verification key from the Domain Name System (DNS). DKIM defines RSA and, in , Ed25519 as signing algorithms. Neither is resistant to attacks by a cryptographically relevant quantum computer (CRQC) running Shor's algorithm . For DKIM, the relevant threat is forgery: an attacker with a CRQC could derive a private signing key from a published public key and sign messages in the name of a domain. This matters for keys that remain published for a long time and for archived messages whose signatures are still checked later. This document discusses the use of post-quantum (PQ) signature algorithms for DKIM1 (DKIM version 1, "v=1" as specified in ). Four candidates are compared: ML-DSA, FN-DSA, SLH-DSA, and SQIsign. Three parameter sets of the first two families are considered in detail: ML-DSA-44, ML-DSA-65 , and FN-DSA-512 . In parallel, standardization of DKIM2 with PQ support is ongoing; DKIM1 currently has no PQ signature algorithm. This document does not define new algorithm identifiers, tags, or registry entries, and it does not modify or . The key words of BCP 14 are used only in , which is a proposal for implementation requirements and not a standard. It does not update , , or , and it does not define algorithm identifiers.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Post-Quantum Signature Algorithms This section describes the PQ signature schemes considered in this document. All are designed to resist attacks by a CRQC. Their public keys or signatures are larger than those of RSA and Ed25519, and the public keys of the lattice-based schemes do not fit in DNS over UDP responses.

ML-DSA ML-DSA is a lattice-based signature scheme built on the Fiat-Shamir with aborts paradigm. Its security rests on the presumed hardness of the Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS) problems. This document considers ML-DSA-44 and ML-DSA-65. Because these schemes are comparatively new, ML-DSA signatures are intended to be used together with a separate traditional DKIM signature.

FN-DSA FN-DSA is a lattice-based signature scheme following the hash-and-sign paradigm. Its security rests on the presumed hardness of the SIS problem over NTRU lattices. FN-DSA has smaller public keys and signatures than ML-DSA. This document considers FN-DSA-512, which is likewise intended to be used together with a separate traditional DKIM signature. FN-DSA is not yet a final standard at the time of writing.

SLH-DSA SLH-DSA is a stateless hash-based signature scheme. Its security is based on the security of hash functions. SLH-DSA was standardized with 12 different parameter sets yielding different security levels, artifact sizes, and performance. In general, SLH-DSA has larger signatures, smaller public keys, and poorer performance compared to lattice-based alternatives. SLH-DSA-SHAKE-128f is used as a representative in this document, because it has the fastest signing of the small-key sets; the "s" variants have smaller signatures but slower signing.

SQIsign SQIsign is an isogeny-based signature scheme. Its security rests on the presumed hardness of finding isogenies between supersingular elliptic curves, a problem that differs fundamentally from the lattice and hash-function assumptions above. SQIsign has the smallest public keys and signatures of all schemes considered, but has poorer performance compared to lattice based schemes. SQIsign is a candidate in NIST's additional signature process and therefore not standardized.

PQ-secure DKIM DKIM supports multiple digital signature algorithms. RFC 6376 defines rsa-sha256 and RFC 8463 defines ed25519-sha256. This document discusses the use of mldsa44-sha256, mldsa65-sha256, and fndsa512-sha256. The suggested implementation requirements for signers and verifiers are given in . The suffix "-sha256" in the algorithm names denotes the hash function used by DKIM to compute the header and body hashes (, Section 3.3) and is independent of any hash function used internally by ML-DSA or FN-DSA. For mldsa44-sha256, mldsa65-sha256, and fndsa512-sha256, the signer applies the signing algorithm of the respective scheme directly to the DKIM header hash as message, using the pure variant (not HashML-DSA) and an empty context string. The algorithm names mldsa44-sha256, mldsa65-sha256, and fndsa512-sha256 are used in this document as working names only. This document does not register them with IANA and does not define new "a=" tag values.

Key Factors and Possible Algorithms DKIM has some key factors, which are relevant for the implementation of post-quantum secure algorithms. These key factors are mainly performance, public-key size and signature size. In short, none of the algorithms mentioned in fits all of the three key factors.

Performance DKIM signatures are signed by the sending server and verified by the receiving server. Calculations are performed on the server, so faster is better. The already standardized algorithms RSA and Ed25519 perform well in sign and verify operations. The PQ alternatives SLH-DSA-SHAKE-128f and SQIsign-I are ~51 and ~49 times slower than RSA-2048 with the sign operation, and ~80 and ~1021 times slower with the verify operation. ML-DSA-44 (~11 times faster sign; nearly the same verify time), ML-DSA-65 (~7 times faster sign; ~2 times slower verify) and FN-DSA-512 (~3 times faster sign, nearly the same verify time) perform better while signing and have about the same verify times. All values are based on calculations by .

Public-Key Size Public DKIM keys are stored as DNS TXT records. Typically these public keys are retrieved using DNS UDP responses, and the traditional maximum UDP size is 512 bytes (smaller is better). RSA-2048 (~256 bytes) and Ed25519 (32 bytes) keys encoded in Base64 fit in such 512 byte packets, PQ alternatives mostly do not. SLH-DSA public keys are 32, 48 or 64 bytes in size, the keys of SQIsign 83, 129 or 169 bytes. SLH-DSA and SQIsign are compatible in this case. ML-DSA (1312, 1952, 2592) and FN-DSA (897, 1793) keys exceed this limit and would need a TCP fallback for the DNS response.

Signature Size DKIM signatures are transmitted in the header of emails and are currently based on RSA and Ed25519. Typically the signature is stored in the email on several devices, like sending and receiving server, and one or more clients (smaller is better). The mentioned traditional algorithms use 64 bytes (Ed25519) up to 256 bytes (RSA-2048), which has no significant impact on email sizes. The PQ alternatives mostly have significantly larger signatures (ML-DSA-44 2420 bytes, ML-DSA-65 3309 bytes, FN-DSA-512 666 bytes, SLH-DSA-SHAKE-128f 17088 bytes), but SQIsign-I in this case has more or less the same signature size (200 bytes). Larger signatures, especially encoded in Base64, mean more space needed for storing emails, which could be a problem especially for the SLH-DSA variants.

PQ Algorithm Consideration Based on the key factors discussed in , none of the mentioned PQ alternatives fulfills all requirements. SQIsign matches most of the key factors but has poor performance and, more importantly, is not standardized. SLH-DSA would increase the email size by at least 17 kilobytes with the first fast variant and also has poor performance. ML-DSA-44, ML-DSA-65 and FN-DSA-512 are the most suitable algorithm variants. They show good performance, but their public keys exceed the 512 byte UDP limit, which makes TCP fallbacks necessary. Their signatures, from 666 bytes (FN-DSA-512) up to 3309 bytes (ML-DSA-65), increase email sizes only moderately. Larger sets (ML-DSA-87, FN-DSA-1024) have larger keys and signatures and exceed the size limits discussed below even further.

Key Sizes For rsa-sha256, the key size for signers should be at least 2048 bits (instead of 1024 bits defined in ), due to newer attacks on smaller key sizes . For the PQ algorithms, the key size is fixed by the parameter set.

Hybrid Signing RSA and Ed25519 are vulnerable to Shor's algorithm . To obtain post-quantum security, a signer needs to add both a traditional signature (rsa-sha256 or ed25519-sha256) and a PQ signature (mldsa44-sha256, mldsa65-sha256, or fndsa512-sha256) to the message, as described in , to get a hybrid construct with two separate signatures. This is more compatible (the traditional algorithm is also used), and if one algorithm is broken, the other part still verifies. A composite construct (one signature combining both algorithms) would break compatibility with the current DKIM system. PQ public keys can exceed the size of a UDP DNS response, so verifiers need to be able to retrieve keys over TCP.

Signature and Key Syntax This section illustrates how DKIM signatures and keys could look if the algorithms discussed here were defined for DKIM. It is informational and does not update or .

Signature Syntax The "a=" tag (, Section 3.5; , Section 4.1) could be extended by adding the following alternatives to the rule sig-a-tag-k:

Key Syntax The "k=" tag (, Section 3.6.1; , Section 4.2) could be extended by adding the following alternatives to the rule key-k-tag-type: The "p=" value would be the base64-encoded public key of the respective scheme, without further encapsulation. See for sample key records.

Proposed Algorithm and Key Requirements Section 3.3 of describes DKIM's hash and signature algorithms and extends them. lists the proposed implementation requirements for DKIM signing algorithms. They are a proposal only, to be adopted, if at all, by a Standards Track document. Algorithms marked as PQ-secure provide post-quantum security only in combination with a traditional signature and only if verifiers require the PQ signature to be valid (see ). ML-DSA-65 offers a higher security level than ML-DSA-44 (NIST category 3 instead of 2) at the cost of larger keys and signatures (several kilobytes); it is therefore only advisable where such higher security needs exist. Some implementations limit the size of individual header fields or of the whole header, which could be a problem for ML-DSA based signatures. Such limits have not been evaluated in this document and need to be checked in an implementation. Proposed Algorithm and Key Size Requirements; (1) = for higher security needs

Algorithm (a=)	Key size	Signer	Verifier	PQ-Secure	Reference
rsa-sha256	< 1024 bits	MUST NOT	MUST NOT	No
rsa-sha256	1024 bits	SHOULD NOT	MUST	No
rsa-sha256	2048 bits	MUST	MUST	No
rsa-sha256	4096 bits	MAY	MUST	No
rsa-sha256	> 4096 bits	MAY	MAY	No
ed25519-sha256	fixed	SHOULD	MUST	No
mldsa44-sha256	fixed	MUST	MUST	Yes (hybrid only)
mldsa65-sha256	fixed	SHOULD (1)	MUST	Yes (hybrid only)
fndsa512-sha256	fixed	SHOULD	SHOULD	Yes (hybrid only)

Transition Considerations A signer that adds a PQ signature to a message needs to also add a traditional signature (rsa-sha256 or ed25519-sha256), so that verifiers without PQ support can still validate the message. Because a selector can publish only one key record in the DNS, the two signatures need to use different selectors; they can use the same d= and, if present, i= values. Without the traditional signature, verifiers that do not support PQ algorithms would treat the message as unsigned. Without the PQ signature, the message would gain no protection against a CRQC (see ). The deployment of PQ signatures is expected to follow that of ed25519-sha256, which is not yet supported by all verifiers. A verifier that supports PQ algorithms validates both signatures; a valid traditional signature alone does not provide PQ security (see ). Since a verifier cannot know whether a domain signs with PQ algorithms, requiring the PQ signature is only possible for domains for which this is known, for example through local policy.

IANA Considerations This document has no IANA actions. The algorithm names used here are working names only (see ). Registration of key types and signature algorithms would have to be requested in a separate Standards Track document.

Security Considerations The security considerations of apply in addition to those below. The algorithms discussed in this document are intended to provide authenticity of DKIM signatures against an adversary with a CRQC. They do so only if a verifier requires both a traditional and a PQ signature as described in . If a verifier accepts a message with only a valid traditional signature, an attacker can remove the PQ signature and forge the traditional one (downgrade). Large public keys and signatures increase DNS response sizes and header lengths; see for the TCP fallback. FN-DSA is not yet a final standard at the time of writing, and its implementation needs particular care, because the floating-point operations used in signing can leak information through side channels.

References Normative References DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. Yahoo Google Fastmail Pty Ltd DomainKeys Identified Mail v2 (DKIM2) permits the owner of a signing domain to document that they have handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient, systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a "chain" that receivers can validate. This permits verifiers to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changes. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message. NIST NIST NIST In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447.

Examples of a Signed Message TBD

Secret Keys

ML-DSA-44

ML-DSA-65

FN-DSA-512

Public Key DNS Records

ML-DSA-44

ML-DSA-65

FN-DSA-512

Signed Message

ML-DSA-44

ML-DSA-65

FN-DSA-512