<?xml version="1.0" encoding="US-ASCII"?>
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc8174 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc8446 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">

]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="bcp" docName="draft-farrell-tls-pqg-02" ipr="trust200902" >
  <front>
    <title abbrev="PQ Guidance for IETF protocols">Post-Quantum Guidance for IETF protocols.</title>

    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity College Dublin</organization>
      <address>
        <postal>
          <street/>
          <city>Dublin</city>
          <region/>
          <code>2</code>
          <country>Ireland</country>
        </postal>
        <phone>+353-1-896-2354</phone>
        <email>stephen.farrell@cs.tcd.ie</email>
      </address>
    </author>

    <date year="2025"/>

    <area>Security Area</area>

    <keyword>TLS, PQC</keyword>

    <keyword>Post-Quantum</keyword>
    <keyword>Guidance</keyword>

    <abstract>
        <t>We provide guidance on the use of post-quantum algorithms for those
            deploying applications using IETF protocols.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

        <t>
            [[This is not an "official" work item anywhere, the -00 was proposed
            to TLS as such, but this version generalises to more than just TLS so 
            is being proposed to the secdispatch list. The author does not expect
            that the current text will garner rough consensus, but wonders if we
            could get something useful that would without adding many words.
            The source for this is in https://github.com/sftcd/pqg/
            PRs are welcome there too.]]
        </t>

        <t>
            Due to concerns about the possible future existence of a
            cryptographically
            relevant quantum computer (CRQC), additional IANA
            <xref target="RFC8446"/>
            codepoints
            have been defined for algorithms that are hoped to remain
            secure even in the face of a CRQC. Adding code-points for
            to the relevant IANA registries often
            doesn't require IETF consensus. This
            means that anyone can register code-points for their
            favoured approach. In particular various government
            entities in various countries have made contradictory
            recommendations in this space, leading to potential
            confusion for those deploying applilcations using TLS.
            For example, anyone can register a PQ algorithm in the 
            TLS registries with the RECOMMENDED column set to 'n'
        </t>

        <t>
            This document sets out a deliberately concise set of
            recommendations for typical uses of post-quantum
            algorithms. This assumes the reader is familiar
            with the topic. Some implementations and environments
            may have to meet other requirements that conflict with
            this guidance.
        </t>

        <t>
            Note that the audience for this document are those deploying
            systems now. This guidance is not aimed at those developing
            IETF protocols, nor implementations of those. Given that it
            seems that the latter groups (protocol developers and 
            implementers) seem determined to define and implement almost
            every possible combination of PQ everything, those deploying
            systems now, that have such PQ all kinds of everything, 
            can benefit from simple guidance that addresses the most
            important aspect of the PQ transition.
        </t>

        <t>
            It is quite likely this guidance will need to be updated with
            a short-ish period (perhaps about two years).
        </t>

      </section>

      <section title="Terminology">
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>

      <section title="Start using hybrid KEMs">

          <t>The main recommendation is to move as soon as practical to use of
              hybrid KEMs, such as X25519MLKEM768.</t>

          <t>Once it becomes practical to do the above, we do not recommend use
              of non-hybrid groups or "pure" PQ KEMs.</t>

      </section>

      <section title="Do nothing for now on signatures">

        <t>
            For almost all deployments, we recommend taking no action at all at
            this point in time in relation to deployment of PQ signatures.
        </t>

        <t>TODO: Define "almost all" somewhat better, but tersely.</t>

      </section>

    <section title="Security Considerations">
        <t>TBD</t>

    </section>

    <section title="Acknowledgements">
        <t>TBD</t>
    </section>

    <section title="IANA Considerations">
        <t>TBD, but probably not needed.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.8174'?>
      <?rfc include='reference.RFC.8446'?>

    </references>

    <!--
    <references title="Informative References">
    </references>
    -->

  </back>
</rfc>
