draft-kampanakis-curdle-pq-ssh-00.xml

<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="exp"
      docName="draft-kampanakis-curdle-pq-ssh-00"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="PQ SSH">Post-quantum public key algorithms for the Secure Shell (SSH) protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-kampanakis-curdle-pq-ssh-00"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- <author fullname="Panos Kampanakis" initials="P." role="editor"  surname="Kampanakis"> -->
   <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
     <organization>Cisco Systems</organization>
     <address>
        <email>pkampana@cisco.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Douglas Stebila" initials="D." surname="Stebila">
     <organization>University of Waterloo</organization>
     <address>
        <email>dstebila@uwaterloo.ca</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Markus Friedl" initials="M." surname="Friedl">
     <organization>OpenSSH</organization>
     <address>
        <email>markus@openbsd.org</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Torben Hansen" initials="T." surname="Hansen">
     <organization>AWS</organization>
     <address>
        <email>htorben@amazon.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Dimitrios Sikeridis" initials="D." surname="Sikeridis">
     <organization>University of New Mexico</organization>
     <address>
        <email>dsike@unm.edu</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date year="2020"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date). With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Security</area>
    <workgroup>CURDLE</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions. 
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>post-quantum SSH</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>This document defines hybrid key exchange methods based on classical ECDH key exchange and post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. It also defines post-quantum public key authentication methods based on post-quantum signature schemes<!--TODO: Update to hybrid if we end up doing hybrid. -->. These methods are defined for use in the SSH Authentication Protocol.</t>
    </abstract>
	<note>
	  <t>EDNOTE: The goal of this draft is to start the standardization of PQ algorithms in SSH early to mitigate the potential record-and-harvest later with a quantum computer attacks. This draft is not expected to be finalized before the NIST PQ Project has standardized PQ algorithms. After NIST has standardized then this document will replace TBD1, TBD3 with the appropriate algorithms and parameters before proceeding to ratification.</t>
	  
	  <t>EDNOTE: Discussion of this work is encouraged to happen on the IETF WG Mailing List or in the GitHub repository which contains the draft: https://github.com/csosto-pk/pq-ssh/issues .</t>
	  
	  <t><strong>Change Log</strong>
	  [EDNOTE: Remove befor publicaton].</t>
	  <dl>
        <dt>draft-kampanakis-curdle-pq-ssh-00</dt> 
		  <dd>
		     <ul>
			   <li>Initial draft</li>
			 </ul>
		  </dd>
      </dl>
	 
    </note>
  </front>
  <middle>
  
    <section numbered="true" toc="default">
      <name>Introduction</name>
		
      <t>Secure Shell (SSH) <xref target="RFC4251" format="default">RFC4251</xref> performs key establishment using key exchange methods based exclusively on (Elliptic Curve) Diffie-Hellman style schemes. SSH <xref target="RFC4252" format="default">RFC4252</xref>, <xref target="RFC8332" format="default">RFC8332</xref>, <xref target="RFC5656" format="default">RFC5656</xref>, <xref target="RFC8709" format="default">RFC8709</xref> also defines public key authentication methods based on RSA or ECDSA/EdDSA signature schemes. The cryptographic security of these key exchange and signature schemes relies on certain instances of the discrete logarithm and integer factorization problems being computationally infeasable to solve for adversaries. </t>
	  <t>However, when sufficiently large quantum computers become available these instances would no longer be computationally infeasable rendering the current key exchange and authentication methods in SSH insecure <xref target="I-D.hoffman-c2pq"/>. While large quantum computers are not available today an adversary can record the encrypted communication sent between the client and server in an SSH session and then later decrypt the communication when sufficiently large quantum computers become available. This kind of attack is  known as a "record-and-harvest" attack. Record-and-harvest attacks do not apply retroactively to authentication but a quantum computer could threaten SSH authentication by impersonating as a legitimate client or server. </t>
	  
	  <t>This document proposes to address the problem by extending the SSH Transport Layer Protocol <xref target="RFC4253" format="default">RFC4253</xref> with hybrid key exchange methods and the SSH Authentication Protocol <xref target="RFC4252" format="default">RFC4252</xref> with public key methods based on post-quantum signature schemes<!--TODO: Update to hybrid if we end up doing hybrid. -->. A hybrid key exchange method maintains the same level of security provided by current key exchange methods, but also adds quantum resistance. The security provided by the individual key exchange scheme in a hybrid key exchange method is independent. This means that the hybrid key exchange method will always be at least as secure as the most secure key exchange scheme executed as part of the hybrid key exchange method.</t>
	  
      <t>In the context of the <xref target="NIST_PQ" format="default">NIST Post-Quantum Cryptography Standardization Project</xref>, key exchange algorithms are formulated as key encapsulation mechanisms (KEMs), which consist of three algorithms:</t>
      <ul>
        <li>'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.</li>
        <li>'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' and outputs a ciphertext 'ct' and shared secret 'ss'. </li>
        <li>'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' and outputs a shared secret 'ss', or in some cases a distinguished error value.</li>
      </ul>
	  	 
      <t>The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated.  IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused.  <!-- A common design pattern for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) transform <xref target="FO" format="default"/> or a variant thereof <xref target="HHK" format="default"/>. --> A weaker security notion is indistinguishability under chosen plaintext attack (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key.  IND-CPA roughly corresponds to security against a passive attacker, and sometimes corresponds to one-time key exchange.</t>
	  
	  <t>The corresponding post-quantum signature algorithms defined in the <xref target="NIST_PQ" format="default">NIST Post-Quantum Cryptography Standardization Project</xref> are </t>
      <ul>
        <li>'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.</li>
        <li>'Sign(m, sk) -> sig': A deterministic signing algorithm, which takes as input a message 'm' and a private key 'sk' and outputs a signature 'sig'. </li>
        <li>'Verify(m, pk, sigma) -> pass/fail': A verification algorithm, which takes as input a message 'm', a public key 'pk' and a signature 'sig' and outputs a verification pass or failure of the signature on the message.</li>
      </ul>
	 
	  <t>The post-quantum KEMs used for hybrid key exchange in the document are TBD1. The post-quantum signature algorithm used for key based authentication is TBD3. [EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.] The post-quantum algorithms are  defined in <xref target="NIST_PQ" format="default">NIST Post-quantum Project</xref>.<!--TODO: Update link reference--> [EDNOTE: Update link. Algorithms can change based on NIST's Round 3 standardization]. </t>
	  
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119" format="default">RFC 2119</xref>.</t>
      </section>
    </section>
	
    <section anchor="kex" numbered="true" toc="default">
	<name>Hybrid Key Exchange</name>
	
    	<section anchor="kex-abstr" numbered="true" toc="default">
    	<name>Hybrid Key Exchange Method Abstraction</name>
    	<t>This section defines the abstract structure of a hybrid key exchange method. The structure must be instantiated with two key exchange schemes. The byte, string and mpint are to be interpreted in this document as described in <xref target="RFC4251" format="default">RFC4251</xref>.</t>

        <t>The client sends</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
       byte SSH_MSG_HBR_INIT
       string C_INIT
]]></artwork>

        <t>where C_INIT would be the concatenation of C_PQ and C_CL.</t>
		
        <t>The server sends</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
       byte SSH_MSG_HBR_REPLY
       string S_REPLY
]]></artwork>

        <t>where S_REPLY would be the concatenation of S_PQ and S_CL.</t>

	    <t>[EDNOTE: Initially we were using S_CL, S_PQ, C_CL, C_PQ which were encoding the server and client client and server classical and post-quantum public key/ciphertext as its own string. We since switched to an encoding method which concatenates them together as a single string in the C_INIT, S_REPLY message. This method concatenates the raw values rather than the length of each value plus the value. The total length of the concatenation is still known, but the relative lengths of the individual values that were concatenated is no longer part of the representation. If that is the WG consensus we need to put a note of this in the Appendix for historical reference and expand on the concatenated string here in this section.] </t>

        <t>C_PQ represents the 'pk' output of the corresponding KEMs' 'KeyGen' at the client. S_PQ represents the ciphertext 'ct' output of the corresponding    KEMs' 'Encaps' algorithm generated by the server to the client's public key. The client decapsulates the ciphertext by using its private key which leads to K_PQ, a post-quantum shared secret for SSH.</t>

        <t>C_CL and S_CL represent the ephemeral public key of the client and server respectively used for the classical (EC)DH key exchange which leads to K_CL, a classical shared secret for SSH.</t>

        <!--<t>For example, the C_CL is represented as a fixed length 32 byte string for Curve25519.</t> -->
    	</section>
			
    	<section numbered="true" toc="default">
    	<name>Key Derivation</name>
    	<t>The shared secrets K_CL and K_PQ are the output from the two key exchange schemes X and Y, respectively, that instantiates an abstract hybrid key exchange method <xref target="kex-abstr" format="default"/>. The SSH shared secret K is derived as the hash algorithm specified in the named hybrid key exchange method name over the concatenation of K_PQ and K_CL:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
        K = HASH(K_PQ, K_CL)
]]></artwork>
		<t><!--is the concatenation of the two shared secrets K_CL and K_PQ. The order of concatenation is the order that the corresponding key exchange scheme appears in the hybrid key exchange method name. K_CL and K_PQ MUST be encoded as octet strings. -->The resulting bytes are fed as to the key exchange method's hash function to generate encryption keys.</t>
		
        <t><strong>FIPS-compliance of shared secret concatenation.</strong>
          <xref target="NIST-SP-800-56C" format="default"/> or <xref target="NIST-SP-800-135" format="default"/> give NIST recommendations for key derivation methods in key exchange protocols.  Some hybrid combinations may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a shared secret from a non-approved algorithm (e.g., post-quantum). <xref target="NIST-SP-800-56C" format="default"/> lists simple concatenation as an approved method for generation of a hybrid shared secret in which one of the constituent shared secret is from an approved method.</t>
    </section>
    	
		<section numbered="true" toc="default">
    	<name>HASH</name>
        <t>The derivation of encryption keys MUST be done according to Section 7.2 in <xref target="RFC4253" format="default">RFC4253</xref> with a modification on the exchange hash H. The hybrid key exchange hash H is the result of computing the HASH, where HASH is the hash algorithm specified in the named hybrid key exchange method name, over the concatenation of the following </t>

<artwork align="left" name="" type="" alt=""><![CDATA[
      string V_C, client identification string (CR and LF excluded)
      string V_S, server identification string (CR and LF excluded)
      string I_C, payload of the client's SSH_MSG_KEXINIT
      string I_S, payload of the server's SSH_MSG_KEXINIT
      string C_INIT, client message octet string
      string S_REPLY, server message octet string
      string K, SSH shared secret
]]></artwork>
		
		<t>The HASH functions used for the definitions in this specification are SHA-256 <xref target="nist-sha2" format="default"/> <xref target="RFC4634" format="default"/>[EDNOTE: Update here if necessary].</t>
    	</section>
			
    	<section anchor="kex-methods" numbered="true" toc="default">
    	<name>Hybrid Key Exchange Method Names</name>
		
		<t>The hybrid key exchange method names defined in this document are </t>
<artwork align="left" name="" type="" alt=""><![CDATA[
      ecdh-nistp256-TBD1-sha256
      x25519-TBD1-sha256
      sntrup4591761x25519-sha512@tinyssh.org (currently implemented)
]]></artwork>
		  <t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
		  
    	  <section numbered="true" toc="default">
    	  <name>ecdh-nistp256-TBD1-sha256</name>
    	  <t>ecdh-nistp256-TBD1-sha256 defines that the classical C_CL or S_CL from the client or server NIST P-256 curve public key as defined in <xref target="nist-sp800-186" format="default"/>. Private and public keys are generated as described therein. Public keys are defined as strings of 32 bytes for NIST P-256. The K_CL shared secret is generated from the exchanged C_CL and S_CL public keys as defined in <xref target="RFC5656" format="default"/> (key agreement method ecdh-sha2-nistp256) with SHA-256 <xref target="nist-sha2" format="default"/> <xref target="RFC4634" format="default"/> <!--instead of SHA-256 as the hash-->.</t>
		  
		  <t>The post-quantum C_PQ or S_PQ string from the client and server are TBD1. The K_PQ shared secret is decapsulated from the ciphertext S_PQ using the client private key [EDNOTE: Placeholder. Update based on the algorithm identified after NIST Round 3 concludes.]</t>
    	  </section>
		  
    	  <section numbered="true" toc="default">
    	  <name>x25519-TBD1-sha256</name>
          <t>x25519-TBD1-sha256 defines that the classical C_CL or S_CL from the client or server is Curve25519 public key as defined in <xref target="RFC7748" format="default"/>. Private and public keys are generated as described therein. Public keys are defined as strings of 32 bytes for Curve25519. The K_CL shared secret is generated from the exchanged C_CL and S_CL public keys as defined in <xref target="RFC8731" format="default"/> (key agreement method curve25519-sha256) with SHA-256 <xref target="nist-sha2" format="default"/> <xref target="RFC4634" format="default"/> <!--instead of SHA-256 as the hash-->.</t>
		
		  <t>The post-quantum C_PQ or S_PQ string from the client and server are TBD1. The K_PQ shared secret is decapsulated from the ciphertext S_PQ using the client private key as defined in [EDNOTE: Placeholder. Update based on the algorithm identified after NIST Round 3 concludes.]</t>
    	  </section>
		  
    	</section> 

    </section>
    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

   <section anchor="key_auth" numbered="true" toc="default">
   <name>Key Authentication</name>
   <t>[EDNOTE: Discuss if hybrid auth keys which combine classical and PQ signatures are necessary. Since authentication cannot be broken retroactively, even if the PQ signature algorithms got broken, we could switch to a classical algorithm to at least keep the classical security. On the other hand, that would take time to deploy while these entities would be vulnerabile to impersonation attacks. Hybrid signatures add some overhead, but could provide the peace of mind of remaining secure with the classical algorithm without scrambling to deploy a change even if the PQ algorithms got broken. ]</t>
	  
	    <section anchor="sig-pk-format" numbered="true" toc="default">
	    <name>Public Key Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
      string    "ssh-TBD3"
      string    key
]]></artwork>
        <t>Here, 'key' is the x-octet public key described in the TBD3 specification.</t>
	    <t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
	    <!--TODO --> 
	    <!-- <t>string    "ssh-sphincsplus"
           string    key</t>
	     <t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t> -->
	    </section>
	    
	    <section anchor="sig-format" numbered="true" toc="default">
	    <name>Signature Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
       string  "ssh-TBD3"
       string  signature
]]></artwork>
        <t>Here, 'signature' is the x-octet signature produced in accordance with the TBD3 specification. </t>
	    <t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
	    <!--TODO --> 
	    <!-- <t>string    "ssh-sphincsplus"
           string    key</t>
	     <t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t> -->
	    </section>

	    <section anchor="sig-alg" numbered="true" toc="default">
	    <name>Signing and Verification</name>
	    <t>Signatures are generated according to the procedure in TBD3 specification</t>
	    
	    <t>Signatures are verified according to the procedure in TBD3 specification</t>
	    <t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
	    </section>
	
	<!-- TODO: Update this section later --> 
	<!-- <section anchor="sshfp" numbered="true" toc="default">
	<name>SSHFP DNS resource records</name>
	<t>Usage and generation of SSHFP DNS resource record is described in [RFC4255]. This section illustrates the generation of SSHFP resource records.</t>
	</section> -->
	
   </section>
   
	<section numbered="true" toc="default">
	<name>Message Size</name>
	<t>An implementation adhering to <xref target="RFC4253" format="default">RFC4253</xref> must be able to support packets with an uncompressed payload length of 32768 bytes or less and a total packet size of 35000 bytes or less (including
   'packet_length', 'padding_length', 'payload', 'random padding', and 'mac'). These numbers represent what must be 'minimally supported' by implementations. This can present a problem when using post-quantum key exchange schemes because some post-quantum schemes can produce much larger messages than what is normally produced by existing key exchange methods defined for SSH. This document does    not define any named domain parameters (see Section 7) that cause any hybrid key exchange method related packets to exceed the minimally supported packet length. This document does not define behaviour in cases where a hybrid key exchange message cause a packet to exceed the minimally supported packet length.</t>
	</section>

    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
    </section>
    <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes requests of IANA for 
      <!-- <t>All drafts are required to have an IANA considerations section (see
     RFC5226 Guidelines for Writing an IANA Considerations Section in RFCs for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the
     case (as above). If there are no requirements for IANA, the section will
     be removed during conversion into an RFC by the RFC Editor.</t> -->
    SSH_MSG_HBR_INIT, SSH_MSG_HBR_REPLY, ecdh-nistp256-TBD1-sha256, x25519-TBD1-sha256, and ssh-TBD3.</t>
    </section>

    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
	  <t>[EDNOTE: The security considerations given in [RFC5656] therefore also applies to the ECDH key exchange scheme defined in this document. Similarly for the X25519 document. PQ Algorithms are newer and standardized by NIST. And more. Should include something about the combination method for the KEM shared secrets. ] </t>
	  <t>[EDNOTE: Discussion on whether an IND-CCA KEM is required or whether IND-CPA suffices.] Any KEM used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is re-used, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform <xref target="FO" format="default"/><xref target="HHK" format="default"/> applied. While it is recommended that implementations avoid reuse of KEM public keys, implementations that do reuse KEM public keys MUST ensure that the number of reuses of a KEM public key abides by any bounds in the specification of the KEM or subsequent security analyses. Implementations MUST NOT reuse randomness in the generation of KEM ciphertexts.</t>
      <t><strong>Public keys, ciphertexts, and secrets should be constant length.</strong> This document assumes that the length of each public key, ciphertext, and shared secret is fixed once the algorithm is fixed.  This is the case for all Round 3 finalists and alternate candidates.</t>
      <t>Note that variable-length secrets are, generally speaking, dangerous.  In particular, when using key material of variable length and processing it using hash functions, a timing side channel may arise.  In broad terms, when the secret is longer, the hash function may need to process more blocks internally.  In some unfortunate circumstances, this has led to timing attacks, e.g. the Lucky Thirteen <xref target="LUCKY13" format="default"/> and Raccoon <xref target="RACCOON" format="default"/> attacks.</t>
      <t>Therefore, this specification MUST only be used with algorithms which have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the Method Names negotiation in <xref target="kex-methods" format="default"/>).</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>
    <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search. These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
	    <?rfc include="reference.RFC.2119.xml"?>
		<?rfc include="reference.RFC.4251.xml"?>
		<?rfc include="reference.RFC.4252.xml"?>
		<?rfc include="reference.RFC.4253.xml"?>
        <!-- <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
             <front>
               <title>Key words for use in RFCs to Indicate Requirement Levels</title>
               <seriesInfo name="DOI" value="10.17487/RFC2119"/>
               <seriesInfo name="RFC" value="2119"/>
               <seriesInfo name="BCP" value="14"/>
               <author initials="S." surname="Bradner" fullname="S. Bradner">
                 <organization/>
               </author>
               <date year="1997" month="March"/>
               <abstract>
                 <t>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.</t>
               </abstract>
             </front>
        </reference> -->
      </references>
      <references>
        <name>Informative References</name>
        <!-- Here we use entities that we defined at the beginning. -->
		<?rfc include="reference.RFC.5656.xml"?>
		<?rfc include="reference.RFC.8332.xml"?>
		<?rfc include="reference.RFC.8709.xml"?>
		<?rfc include="reference.RFC.4634.xml"?>
		<?rfc include="reference.RFC.8731.xml"?>
		<?rfc include="reference.RFC.7748.xml"?>
		<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.hoffman-c2pq.xml"?>
        <!-- the following is the minimum to make xml2rfc happy -->
        <reference anchor="NIST_PQ" target="https://csrc.nist.gov/projects/post-quantum-cryptography">
          <front>
               <title>Post-Quantum Cryptography</title>
               <author>
                 <organization>NIST</organization>
               </author>
               <date year="2020"/>
             </front>
        </reference>
        <reference anchor="nist-sp800-186" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186-draft.pdf">
          <front>
               <title>SP 800-186</title>
               <author>
                 <organization>NIST</organization>
               </author>
               <date year="2019"/>
             </front>
        </reference>
        <reference anchor="nist-sha2" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
               <title>FIPS PUB 180-4</title>
               <author>
                 <organization>NIST</organization>
               </author>
               <date year="2015"/>
             </front>
        </reference>
        <reference anchor="HHK">
          <front>
            <title>A Modular Analysis of the Fujisaki-Okamoto Transformation</title>
            <seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
            <seriesInfo name="Theory of Cryptography" value="pp. 341-371"/>
            <author initials="D." surname="Hofheinz" fullname="Dennis Hofheinz">
              <organization/>
            </author>
            <author initials="K." surname="Hövelmanns" fullname="Kathrin Hövelmanns">
              <organization/>
            </author>
            <author initials="E." surname="Kiltz" fullname="Eike Kiltz">
              <organization/>
            </author>
            <date year="2017"/>
          </front>
        </reference>
        <reference anchor="FO">
          <front>
            <title>Secure Integration of Asymmetric and Symmetric Encryption Schemes</title>
            <seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
            <seriesInfo name="Journal of Cryptology" value="Vol. 26, pp. 80-101"/>
            <author initials="E." surname="Fujisaki" fullname="Eiichiro Fujisaki">
              <organization/>
            </author>
            <author initials="T." surname="Okamoto" fullname="Tatsuaki Okamoto">
              <organization/>
            </author>
            <date year="2011" month="December"/>
          </front>
        </reference>
        <reference anchor="NIST-SP-800-56C" target="https://doi.org/10.6028/NIST.SP.800-56Cr2">
          <front>
            <title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2020" month="August"/>
          </front>
        </reference>
        <reference anchor="NIST-SP-800-135" target="https://doi.org/10.6028/NIST.SP.800-135r1">
          <front>
            <title>Recommendation for Existing Application-Specific Key Derivation Functions</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2011" month="December"/>
          </front>
        </reference>
        <reference anchor="RACCOON" target="https://raccoon-attack.com/">
          <front>
            <title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)</title>
            <author initials="R." surname="Merget">
              <organization/>
            </author>
            <author initials="M." surname="Brinkmann">
              <organization/>
            </author>
            <author initials="N." surname="Aviram">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky">
              <organization/>
            </author>
            <author initials="J." surname="Mittmann">
              <organization/>
            </author>
            <author initials="J." surname="Schwenk">
              <organization/>
            </author>
            <date year="2020" month="September"/>
          </front>
        </reference>
        <reference anchor="LUCKY13" target="https://ieeexplore.ieee.org/iel7/6547086/6547088/06547131.pdf">
          <front>
            <title>Lucky Thirteen: Breaking the TLS and DTLS record protocols</title>
            <author initials="N.J." surname="Al Fardan">
              <organization/>
            </author>
            <author initials="K.G." surname="Paterson">
              <organization/>
            </author>
            <date year="2013"/>
          </front>
        </reference>
      </references>
    </references>
    <!-- <section anchor="app-additional" numbered="true" toc="default">
      <name>Additional Stuff</name>
      <t>This becomes an Appendix.</t>
    </section> -->
 </back>
</rfc>