<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 4.0.5) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-hoffman-pq-dnssec-considerations-00" category="info" submissionType="IETF">
  <front>
    <title abbrev="Selecting PQ DNSSEC">Considerations for Selecting Post-Quantum Algorithms for DNSSEC</title>

    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization>ICANN</organization>
      <address>
        <email>paul.hoffman@icann.org</email>
      </address>
    </author>

    <date year="2026" month="July" day="19"/>

    
    
    

    <abstract>


<?line 20?>

<t>This draft lists many of the considerations that the DNS community needs to balance
when it is deciding which post-quantum algorithms to standardize for DNSSEC.</t>

<t>This draft is definitely not meant to become an RFC.</t>



    </abstract>



  </front>

  <middle>


<?line 27?>

<section anchor="considerations-for-selecting-post-quantum-algorithms-for-dnssec"><name>Considerations for Selecting Post-Quantum Algorithms for DNSSEC</name>

<t>This document lists many of the considerations that the DNS community needs to balance
when it is deciding which post-quantum algorithms to standardize for DNSSEC.
The list here is not meant to be exhaustive, nor are the items listed in any particular order.
The various considerations are not all equal,
and different parts of the DNS community may find some considerations more important than others.</t>

<t>This list is a brief summary, and does not contain all the details of each consideration 
that might be important to each part of the DNS community.
It is meant to help the DNS community remember the significant tradeoffs that need to be made when picking a post-quantum algorithm for DNSSEC.</t>

<section anchor="standardization"><name>Standardization</name>

<t>Does an algorithm have to be standardized by the US NIST?</t>

<t>If an algorithm isn't standardized by US NIST, what other standards bodies are aceptable?</t>

</section>
<section anchor="size-of-records"><name>Size of Records</name>

<t>Some proposals have big public keys but acceptable-sized signatures.
Some proposals have big signtures but acceptable-sized public keys.
Some proposals have big signtures and big public keys.</t>

<t>Proposed terminology for sizes of signatures:</t>

<t><list style="symbols">
  <t>Tiny: &lt;400 bytes (three fit comfortably in a UDP packet for NXDOMAIN responses)</t>
  <t>Small: 400-1400 bytes (one or two fit comfortably in a UDP packet)</t>
  <t>Large: 1400-3000 bytes (forces TCP)</t>
  <t>Jumbo: &gt;3000 bytes (causes noticeable traffic size)</t>
</list></t>

</section>
<section anchor="cpu-usage-other-than-tcp"><name>CPU Usage other than TCP</name>

<t>Some proposals take much more effort than current algorithms to sign.
Some proposals take much more effort than current algorithms to validate.
Some proposals take much more effort than current algorithms both to sign and validate.</t>

</section>
<section anchor="changes-needed-to-the-dns-protocol"><name>Changes Needed to the DNS Protocol</name>

<t>Some proposals require changes to how resolvers get keys and/or signatures in order to be efficient.
These changes require protocol changes that have to be rolled out with the proposed algorithms.</t>

</section>
<section anchor="likelihood-of-inclusion-in-hsms"><name>Likelihood of Inclusion in HSMs</name>

<t>Some proposals are difficult to implement in HSM hardware.
Some zones are required by policy to use hardware HSMs.</t>

</section>
<section anchor="amount-and-assuredness-of-cryptanalysis"><name>Amount and Assuredness of Cryptanalysis</name>

<t>Some proposals are considered likely to be secure but have some worrisome aspects.
For example, some proposals require very careful implementation of signing in order to not leak the private key.
Determining the assuredness is very hard to quantify across the cryptographic community.</t>

</section>
</section>
<section anchor="additional-resources"><name>Additional Resources</name>

<t>The following may be useful for comparing many post-quantum signature schemes against each other.</t>

<t><eref target="https://pqshield.github.io/nist-sigs-zoo/">Post-Quantum Signature Schemes from PQShield</eref></t>

<t><eref target="https://blog.cloudflare.com/ml-dsa-will-have-to-do/">Why we cannot wait for better post-quantum signature algorithms from Cloudflare</eref></t>

</section>


  </middle>

  <back>








  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA81WTW/cNhC981cQyKFJYa23aS9dFE2NdYK4aNxN1kYLBD1Q
0kgiTIoKSe1G/vV9Q2m/bAdtkUsPhm2R8+bNzJsZZlkmoo6GFnLp2qBL8ipq
/CUr5+WaDBVRt7VcuRCz971qY2/lhamd17Gx463L6/X69VKoPPe0WRwbvd+d
la5olYWT0qsqZo2rKqvarPuUlW0IVGTFifNsPhe68wsZfR/iy/n8x/lLEfrc
6hBwHocOUFevb96IQsWF1G3lhFB9bJxfCCkz/Eh8DQu5msm3o7P0bSSxUr05
+ex8rVp9n5wDeHlxfZ2+k1XaLGSH+7OJ8y+6UG07g4UQrfMWNhtaCMEcDv9l
WSZVHqJXRRTiptFhjFwaHWKQwBmkq2RsSJ5Gjk8qpu/IHM6s7VsdB9kSlTh0
MldGtQWJbUOt1FEyMhW65HxvG100suNSfZpKpQ6lgnGIqi2VL/U9HVVudsIw
AVYaXsnAr4vSErCSbwIhkqqVH96wFUdpdVkaEuLZV+tnIuGK3lL7f83UDfwx
M9mQJ4Z8kCBJnxsFzUIGZzjzUuEak0Q6gcymVEKakuPqlI+66I3yUCACG+E3
ymvXh4fhMhA7U8ZIAmlzJkBRlrqqQAX+GS3scnWaE6sGiZKWMnD9HgBbx5HY
zvmYwmhQXwcMH3bCSAHjt5K511TJ0Fur/HAmEwFHYxYAGxVHBoJMoST8axIj
Usj2iVspUvmsrpvIaTvy78brHM6T0czEVWKzz3pDpnsiaE+WbE4+HQVdt7ri
3oWJVyWhmycJsWCm4lkcyKSXThd3LBT1BZGcts+zZ3K9F0yKT4hLzotqj0wa
taHJ0ZG8SpkPieLtWl5frW9eCXFVnRrq0H4TH9lM989AGFGkiu3vBJm7UtOo
GlVQF1Vu6NXIlDWNxH5AN+OmEGsWRecdIlWoV6KZ61p2fW50Ie9oAFwP5RU7
oCwkEpxUFXtPUMqXQPhOuvI0xJGPf4PBgntADelfJROuInmrW2dcPaQCsY8k
wANTDOdv5Y1uh4X86Yf5HImMuPI8Np7Q6ZplbCuWYo7px2qWt5criLG4o5gw
r/+8/P3dxdU19BU6SJrCCyCuLWS/kEDMvjuCdS1SDQVu3T9hM8hvytdYTwyQ
fT8/oMCmwO+b5Ypv/drb3C3kz8c3CsycsQ11QZxeFnkFvacUvEh1X65u5W1Q
NU1aSY0OzEcCiOoOrdCjB9NooIo5j9eL3qdZ82BYIruPqvefUTbK6FJF+kqk
HNHtSCW9HHBTFmBWI1XX6Pqx73eTAyqKrnDmUT48xq2G42Iy5ZHjtlx/ZzYY
k7KGNFKXwN15kt1ObVzlNNp324FrosE4jfpwwNz56CYSB2fc3EeTwztjwNuh
mbaaI212VPH1kIYx2N/0HRndOFdyE1y1hen5/cSs3q7fPW59nha8UHgppdGK
sWworePRBEx8ucW1qUj3EPhoNgWQJlPn0JwD20OVe5PkcuR1YV3PVUN1LkJA
okrApEZd+gHzoVVmCPppfrs1AleGwxt2I5UgBkpTJqUrrbqt816nv1To8BSB
/zcoEH1WHNjZeOlxpVHVQRbwVuGhuM/BuLimacLL4bi4vAENqbupIHoDxbEo
ZuKSxrHEFnyojiLGGku+OEeMkvaMrgYMSu9CGJ89nBJXe9Xh0XK8BvHmuihL
zayUwTgPruc5IdIrooJO3JZ98vJHflAKjoZHGDCwXcczfoYcb7i9dmUoGoSN
pNfY6ngApK2cRgdcfzx50K33RuvJqPLO4v2/bjSZ8q/nTYxdWJyfd59C+jKr
odI+n2l33uJxgWVQh+zeuXOMqo9/NIPcIm68s5HUrdLj4M0pIpFfYns0AZLv
pXF9WeFpRQfvORbDrNgfzJCHc2uyMqhsq43JWDdZdFmZePwNoYgu/BsNAAA=

-->

</rfc>

