On 25 Jul 2026, you wrote: > He understands that our main constraint is key size, since the base64 > version of a key needs to fit in a text RR and the longer they are, the > harder it is for people to copy and paste them.
About that... I'm skeptical that quantum computers will ever work in practice, but DKIM has always had a related problem here. RSA keys already strain the ability of DNS to fit them into a UDP packet. 2048-bit keys are normal today, and 4096-bit would be expected to force TCP. If everyone supported it, ed25519 would provide some breathing room. But it is not PQC, and some of the PQC proposals have very fat public keys. While at least one is as small at ed25519, we can't assume all of the PQC proposals will turn out to be sound, so if we prepare at all, we should prepare for large public keys. DKIM's current design makes it harder on the DNS because of the use of TXT records only. The necessary base64 translation makes a key a third larger on the wire. Long ago, as part of the DNSSEC project, a record "KEY" (25), was defined that holds any key efficiently and can have new algorithms added by standards action. Originally, it was going to be a generic holder for keys of any use, and had a "protocol" field that was "3" for DNSSEC's own use and allowed other types for other uses. It would have been perfect for use in a revised DKIM, but later, the DNSSEC people decided it was somehow toxic for KEY records unrelated to DNSSEC itself to exist, so all non-"3" records were banned. After that, DNSSEC changed so much that they wanted to make sure that the current version was invisible to any computer still trying the validate under the early draft's rules, so now DNSSEC-related keys are under "DNSKEY" (48) records. But they never released the old "KEY" record for general use. That problem could be quicky resolved by registering a new RR. For speedy implmentation, just specify that it has identical translation between zonefile and wire as for type 25. Then afterwards it's just as if generic KEY RRs were never banned. For a future DKIM use, the record would only replace the "p=" and "k=" tags. Everything else would be left in the TXT record which would still exist at the same name. ---- Michael Deutschmann <[email protected]> _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
