<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!--
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
-->
<!ENTITY rfc4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc5288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5288.xml">
<!ENTITY ietf-tls-rfc4346-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4346-bis.xml">
<!ENTITY ietf-tls-ctr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-ctr.xml">
<!ENTITY rescorla-tls-suiteb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rescorla-tls-suiteb.xml">
<!ENTITY I-D.draft-mcgrew-fundamental-ecc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-fundamental-ecc-04.xml">
<!ENTITY I-D.draft-mcgrew-tls-aes-ccm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-tls-aes-ccm-03.xml">
<!--
<!ENTITY I-D.draft-ietf-tls-rfc4347-bis   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tls-rfc4347-bis-03.xml">
-->
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
<!ENTITY rfc5430 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5430.xml">
<!ENTITY rfc4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc5639 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5639.xml">
<!ENTITY rfc6090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6090.xml">
<!ENTITY rfc6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY rfc6655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6655.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="info" docName="draft-mcgrew-tls-aes-ccm-ecc-07"
     ipr="trust200902">
  <front>
    <title abbrev="AES-CCM ECC TLS">AES-CCM ECC Cipher Suites for TLS</title>

    <author fullname="David McGrew" initials="D" surname="McGrew">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>13600 Dulles Technology Drive</street>

          <city>Herndon</city>

          <code>20171</code>

          <region>VA</region>

          <country>USA</country>
        </postal>

        <email>mcgrew@cisco.com</email>
      </address>
    </author>

    <author fullname="Daniel V. Bailey" initials="D" surname="Bailey">
      <organization>RSA/EMC</organization>

      <address>
        <postal>
          <street>174 Middlesex Tpke.</street>

          <city>Bedford</city>

          <code>01463</code>

          <region>MA</region>

          <country>USA</country>
        </postal>

        <email>dbailey@rsa.com</email>
      </address>
    </author>

    <author fullname="Matthew Campagna" initials="M." surname="Campagna">
      <organization>Certicom Corp.</organization>

      <address>
        <postal>
          <street>5520 Explorer Drive #400</street>

          <city>Mississauga</city>

          <region>Ontario</region>

          <code>L4W 5L1</code>

          <country>Canada</country>
        </postal>

        <email>mcampagna@certicom.com</email>
      </address>
    </author>

    <author fullname="Robert Dugal" initials="R." surname="Dugal">
      <organization>Certicom Corp.</organization>

      <address>
        <postal>
          <street>5520 Explorer Drive #400</street>

          <city>Mississauga</city>

          <region>Ontario</region>

          <code>L4W 5L1</code>

          <country>Canada</country>
        </postal>

        <email>rdugal@certicom.com</email>
      </address>
    </author>

    <date month="July" year="2013"/>

    <area>Security Area</area>

    <workgroup>TLS Working Group</workgroup>

    <abstract>
      <t>This memo describes the use of the Advanced Encryption Standard (AES)
      in the Counter and CBC-MAC Mode (CCM) of operation within Transport
      Layer Security (TLS) to provide confidentiality and data origin
      authentication. The AES-CCM algorithm is amenable to compact
      implementations, making it suitable for constrained environments. The
      ciphersuites defined in this document use Elliptic Curve Cryptography
      (ECC), and are advantageous in networks with limited bandwidth.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes the use of Advanced Encryption Standard (AES)
      <xref target="AES"/> in Counter with CBC-MAC Mode (CCM) <xref
      target="CCM"/> in several TLS ciphersuites. AES-CCM provides both
      authentication and confidentiality and uses as its only primitive the
      AES encrypt operation (the AES decrypt operation is not needed). This
      makes it amenable to compact implementations, which is advantageous in
      constrained environments. Of course, adoption outside of constrained
      environments is necessary to enable interoperability, such as that
      between web clients and embedded servers, or between embedded clients
      and web servers. The use of AES-CCM has been specified for IPsec ESP
      <xref target="RFC4309"/> and 802.15.4 wireless networks <xref
      target="IEEE802154"/>.</t>

      <t>Authenticated encryption, in addition to providing confidentiality
      for the plaintext that is encrypted, provides a way to check its
      integrity and authenticity. Authenticated Encryption with Associated
      Data, or AEAD <xref target="RFC5116"/>, adds the ability to check the
      integrity and authenticity of some associated data that is not
      encrypted. This memo utilizes the AEAD facility within TLS 1.2 <xref
      target="RFC5246"/> and the AES-CCM-based AEAD algorithms defined in
      <xref target="RFC5116"/> and <xref target="RFC6655"/>
      <!-- <xref target="I-D.draft-mcgrew-tls-aes-ccm"/> -->. All of these
      algorithms use AES-CCM; some have shorter authentication tags, and are
      therefore more suitable for use across networks in which bandwidth is
      constrained and message sizes may be small.</t>

      <t>The ciphersuites defined in this document use Ephemeral Elliptic
      Curve Diffie-Hellman (ECDHE) as their key establishment mechanism; these
      ciphersuites can be used with DTLS <xref target="RFC6347"/>.</t>

      <section title="Conventions Used In This Document">
        <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"/>.</t>
      </section>
    </section>

    <section anchor="suites" title="ECC based AES-CCM Cipher Suites">
      <t>The ciphersuites defined in this document are based on the AES-CCM
      authenticated encryption with associated data (AEAD) algorithms
      AEAD_AES_128_CCM and AEAD_AES_256_CCM described in <xref
      target="RFC5116"/>. The following ciphersuites are defined:</t>

      <t><list style="hanging">
          <t>CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM =
          {TBD1,TBD1}<vspace/> CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM =
          {TBD2,TBD2}<vspace/> CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
          = {TBD3,TBD3}<vspace/> CipherSuite
          TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {TBD4,TBD4}<vspace/></t>
        </list></t>

      <t>These ciphersuites make use of the AEAD capability in TLS 1.2 <xref
      target="RFC5246"/>. Note that each of these AEAD algorithms uses
      AES-CCM. Ciphersuites ending with "8" use eight-octet authentication
      tags; the other ciphersuites have 16 octet authentication tags.</t>

      <t>The HMAC truncation option described in Section 7 of <xref
      target="RFC6066"/> (which negotiates the "truncated_hmac" TLS extension)
      does not have an effect on the cipher suites defined in this note,
      because they do not use HMAC to protect TLS records.</t>

      <t>The "nonce" input to the AEAD algorithm is as defined in <xref
      target="RFC6655"/>.
      </t>
<!-- 
     <xref
      target="RFC5288"/>; for the convenience of the reader, we summarize the
      details in this note. The "nonce" SHALL be 12 bytes long and constructed
      as follows:</t>

      <figure>
        <artwork align="center"><![CDATA[
struct {
   case client:
      uint32 client_write_IV;  // low order 32-bits
   case server:
      uint32 server_write_IV;  // low order 32-bits
   uint64 seq_num;
} CCMNonce.]]></artwork>
      </figure>
-->
      <t>In DTLS, the 64-bit seq_num field is the 16-bit DTLS epoch field
      concatenated with the 48-bit sequence_number field. The epoch and
      sequence_number appear in the DTLS record layer.</t>

      <t>This construction allows the internal counter to be 32-bits long,
      which is a convenient size for use with CCM.</t>

      <t>These ciphersuites make use of the default TLS 1.2 Pseudorandom
      Function (PRF), which uses HMAC with the SHA-256 hash function.</t>

      <t>The ECDHE_ECDSA key exchange is performed as defined in <xref
      target="RFC4492"/>, with the following additional stipulations:</t>

      <t><list style="symbols">

	  <t>
	    Curves with a cofactor equal to one SHOULD be used; this simplifies 
	    their use.  
	  </t>

          <t>The uncompressed point format MUST be supported. Other point
          formats MAY be used.</t>

          <t>The client SHOULD offer the elliptic_curves extension and the
          server SHOULD expect to receive it.</t>

          <t>The client MAY offer the ec_point_formats extension, but the
          server need not expect to receive it.</t>

          <t><xref target="RFC6090"/> MAY be used as an implementation
          method.</t>

          <t>
	    The server's certificate SHOULD contain a suitable ECC
	    public key, SHOULD be signed with a suitable ECC public
	    key, and the elliptic curve and hash function SHOULD be
	    selected to ensure a uniform security level; guidance on
	    acceptable choices of hashes and curves that can be used
	    with each ciphersuite is detailed in <xref
	    target="reqts"/>.  The Signature Algorithms extension
	    (Section 7.4.1.4.1 of <xref target="RFC5246"/>) SHOULD be
	    used to indicate support of those signature and hash
	    algorithms.  If a client certificate is used, the same
	    criteria SHOULD apply to it. </t>

        </list></t>

      <t>Implementations of these ciphersuites will interoperate with <xref
      target="RFC4492"/>, but can be more compact than a full implementation
      of that RFC.</t>

      <section anchor="newaead" title="AEAD algorithms">
        <t>The following AEAD algorithms are used: </t>

        <t><list style="hanging">
            <t>AEAD_AES_128_CCM is used in the
            TLS_ECDHE_ECDSA_WITH_AES_128_CCM ciphersuite,</t>

            <t><vspace/> AEAD_AES_256_CCM is used in the
            TLS_ECDHE_ECDSA_WITH_AES_256_CCM ciphersuite,<vspace/></t>

            <t><vspace/> AEAD_AES_128_CCM_8 is used in the
            TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ciphersuite, and<vspace/></t>

            <t><vspace/> AEAD_AES_256_CCM_8 is used in the
            TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 ciphersuite.<vspace/></t>
          </list><!-- <xref
	  target="draft-mcgrew-tls-aes-ccm"/> --></t>
      </section>

      <section anchor="reqts" title="Requirements on Curves and Hashes">

   <t>
     Implementations SHOULD select elliptic curves and hash functions
     so that AES-128 is used with a curve and a hash function
     supporting a 128-bit security level, and AES-256 is used with a
     curve and a hash function supporting a 192-bit or 256-bit
     security level.  More detailed guidance on cryptographic
     parameter selection is given in <xref target="SP800-57"/> (see
     especially Tables 2 and 3).
   </t>

   <t>
     <xref target="rec"/> describes suitable curves and hash functions
     that are widely available.  
   </t>

<!--
        <t>The curves and hash algorithms that can be used with each
        ciphersuite are as follows. The ciphersuites
        TLS_ECDHE_ECDSA_WITH_AES_128_CCM and
        TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST be used with one of the
        following combinations:</t>

        <t><list style="hanging">
            <t>secp256r1 and SHA-256, or</t>

            <t>secp384r1 and SHA-384, or</t>

            <t>secp521r1 and SHA-512.</t>
          </list></t>

        <t>The ciphersuites TLS_ECDHE_ECDSA_WITH_AES_256_CCM and
        TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST be used with one of the
        following combinations:</t>

        <t><list style="hanging">
            <t>secp384r1 and SHA-384, or</t>

            <t>secp521r1 and SHA-512.</t>
          </list></t>


-->

        <!--       
    <t>
    The curves and hash algorithms that can be used with each 
    ciphersuite are described in the following table.
    </t>

<texttable>
     <ttcol align="left"> CipherSuite </ttcol>
     <ttcol align="left"> Curve and Hash </ttcol>
     
     <c>
       	TLS_ECDHE_ECDSA_WITH_AES_128_CCM   
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 
     </c>

     <c>
       secp256r1, SHA-256
       </c>
     <c>
       </c>
     <c>
       secp384r1, SHA-384
       </c>
     <c>
       </c>
     <c>
       secp521r1, SHA-512
       </c>

     <c>
       	TLS_ECDHE_ECDSA_WITH_AES_256_CCM   
	TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 
     </c>

     <c>
        secp384r1, SHA-384
       </c>
     <c>
       </c>
     <c>
       secp521r1, SHA-512
       </c>

   </texttable>
-->
      </section>
    </section>

    <section title="TLS Versions">
      <t>These ciphersuites make use of the authenticated encryption with
      additional data defined in TLS 1.2 <xref target="RFC5288"/>. They MUST
      NOT be negotiated in older versions of TLS. Clients MUST NOT offer these
      cipher suites if they do not offer TLS 1.2 or later. Servers which
      select an earlier version of TLS MUST NOT select one of these cipher
      suites. Earlier versions do not have support for AEAD; for instance, the
      TLSCiphertext structure does not have the "aead" option in TLS 1.1.
      Because TLS has no way for the client to indicate that it supports TLS
      1.2 but not earlier, a non-compliant server might potentially negotiate
      TLS 1.1 or earlier and select one of the cipher suites in this document.
      Clients MUST check the TLS version and generate a fatal
      "illegal_parameter" alert if they detect an incorrect version.</t>
    </section>

    <section title="History">
    <t>
      The 07 version removed the mandatory-to-implement elliptic curves
      and hash functions, and replaced them with non-normative guidance, 
      which is in Appendix A.  
    </t>
      <t>
	The 06 version replaced obsoleted references with updated ones
	to RFC6066, RFC6655, RFC5246, fixes a boilerplate error, and
	corrects the section reference for the truncated HMAC RFC.  It
	also changes the mandatory-to-implement curves and hash
	algorithms to be less restrictive, so that the specification
	can potentially be used with curves other than secp256r1,
	secp384r1, and secp521r1.   A reference to SP 800-57
	was added to provide guidance on parameter selection.  
      </t>
      <t>
	The 05 version updated the IANA considerations.
      </t>
      <t>
	The 04 version changed the intended status to "Informational",
	and removed the redundant definition of the AEAD nonce and
	replaced it with a reference to draft-mcgrew-tls-aes-ccm, to
	avoid incompatible descriptions.
      </t>

      <t>The 03 version removed materials that are redundant with
      draft-mcgrew-tls-aes-ccm, and replaced them with references to that
      draft. That draft has been approved for RFC and will be a suitable
      stable normative reference.</t>

      <t>The 02 version removed the AEAD_AES_128_CCM_12 and
      AEAD_AES_256_CCM_12 AEAD algorithms, because they were not needed in any
      ciphersuites. The AES-256 ciphersuites were retained, however, to
      provide a secure cipher for use with the higher security curves
      secp384r1 and secp521r1.</t>

      <t>This section is to be removed by the RFC editor upon publication.</t>
    </section>


    <section anchor="IANA" title="IANA Considerations">
      <t>
	IANA is requested to assign the values for the ciphersuites
	defined in Section <xref target="suites"/> from the TLS and
	DTLS CipherSuite registries.  IANA, please note that the
	DTLS-OK column should be marked as "Y" for each of these
	algorithms.
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <section title="Perfect Forward Secrecy">
        <t>The perfect forward secrecy properties of ephemeral Diffie-Hellman
        ciphersuites are discussed in the security analysis of <xref
        target="RFC5246"/>. This analysis applies to the ECDHE
        ciphersuites.</t>
      </section>

      <section title="Counter Reuse">
        <t>AES-CCM security requires that the counter is never reused. The IV
        construction in <xref target="suites"/> is designed to prevent counter
        reuse.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This draft borrows heavily from <xref target="RFC5288"/>. Thanks are
      due to Robert Cragie for his great help in making this work complete, correct, and useful,
      and to Peter Dettman for his review.</t>

      <t>This draft is motivated by the considerations raised in the Zigbee
      Smart Energy 2.0 working group.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc6090;
      &rfc5639;

      &rfc6347;

<!--      &I-D.draft-mcgrew-tls-aes-ccm; -->

      &rfc6655;

      &rfc4492;

      &rfc2119;

      <!--
			&rfc4347;
-->

      &rfc6066;

      &rfc5288;

      &rfc5116;

      &rfc5246;

      <reference anchor="CCM">
        <front>
          <title>Recommendation for Block Cipher Modes of Operation: The CCM
          Mode for Authentication and Confidentiality</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date month="May" year="2004"/>
        </front>

        <seriesInfo name="SP" value="800-38C"/>
      </reference>

      <reference anchor="SP800-57">
        <front>
          <title>Recommendation for Key Management - Part 1: General
          (Revision 3)
</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date month="July" year="2012"/>
        </front>

        <seriesInfo name="SP" value="800-57 Part 1"/>
      </reference>

      <reference anchor="AES">
        <front>
          <title>Specification for the Advanced Encryption Standard
          (AES)</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date month="November" year="2001"/>
        </front>

        <seriesInfo name="FIPS" value="197"/>
      </reference>
    </references>

    <references title="Informative References">
      &rfc4309;

      <reference anchor="IEEE802154">
        <front>
          <title>Wireless Personal Area Networks</title>

          <author>
            <organization>Institute of Electrical and Electronics
            Engineers</organization>
          </author>

          <date year="2006"/>
        </front>

        <seriesInfo name="IEEE Standard" value="802.15.4-2006"/>
      </reference>

<!--      &rfc4346; -->
    </references>


    <section anchor="rec" title="Recommended Curves and Algorithms">
      <t>
	This memo does not mandate any particular elliptic curves or
	cryptographic algorithms, for the sake of flexibility.
	However, since the main motivation for the AES-CCM-ECC
	ciphersuites is their suitability for constrained
	environments, it is valuable to identify a particular suitable
	set of curves and algorithms.  
      </t>
      <t>
	This appendix identifies a set of elliptic curves and
	cryptographic algorithms that meet the requirements of this
	note, which are widely supported and believed to be secure.
      </t>

      <t> The curves and hash algorithms recommended for each ciphersuite are:
      </t>
      <t>
	<list style="hanging">
	  <t> An implementation that includes either
	  TLS_ECDHE_ECDSA_WITH_AES_128_CCM or
	  TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST support the
	  secp256r1 curve and the SHA-256 hash function.
	  </t>
	  <t>
	    An implementation that includes either
	    TLS_ECDHE_ECDSA_WITH_AES_256_CCM or
	    TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST support the
	    secp384r1 curve and the SHA-384 hash function, and MAY
	    support the secp521r1 curve and the SHA-512 hash function.
	  </t>
	</list>
      </t>

      <t>
	More information about the secp256r1, secp384r1, and secp521r1 curves
	is available in Appendix A of <xref target="RFC4492"/>.
      </t>

      <t>
	It is not necessary to implement the above curves and hash
	functions in order to conform to this specification.  Other
	elliptic curves, such as the Brainpool curves <xref
	target="RFC5639"/> for example, meet the criteria laid out in
	this memo.
      </t>

<!--
      <t>

	The following curves and
	algorithms are RECOMMENDED:
      </t>
      <t>
      <list>
	<t>
	  The curve secp256r1, which is equivalent to the
          NIST P-256 curve. 
	</t>

          <t>
	    The server's certificate contains an ECDSA-capable public
	    key, is signed with ECDSA, and uses the SHA-256 hash function. 
	    The Signature Algorithms extension (Section 7.4.1.4.1 of
	    <xref target="RFC5246"/>) is used to indicate support of those
          signature and hash algorithms.  If a client certificate is used, the
          same conditions apply to it. The acceptable choices of hashes and
          curves that can be used with each ciphersuite are detailed in <xref
          target="reqts"/>.</t>

      </list>

	The following curves and
	algorithms are RECOMMENDED:
      </t>
      <t>
      <list>
          <t>The curve secp256r1, and the curves secp384r1
          and secp521r1 MAY be supported; these curves are equivalent to the
          NIST P-256, P-384, and P-521 curves. Note that all of these curves
          have cofactor equal to one.</t>

          <t>The server's certificate MUST contain an ECDSA-capable public
          key, it MUST be signed with ECDSA, and it MUST use SHA-256, SHA-384,
          or SHA-512. The Signature Algorithms extension (Section 7.4.1.4.1 of
          <xref target="RFC5246"/>) MUST be used to indicate support of those
          signature and hash algorithms. If a client certificate is used, the
          same conditions apply to it. The acceptable choices of hashes and
          curves that can be used with each ciphersuite are detailed in <xref
          target="reqts"/>.</t>

      </list>

The following curves and
	algorithms are RECOMMENDED:
      </t>
      <t>
      <list>
          <t>The curve secp256r1 MUST be supported, and the curves secp384r1
          and secp521r1 MAY be supported; these curves are equivalent to the
          NIST P-256, P-384, and P-521 curves. Note that all of these curves
          have cofactor equal to one.</t>

          <t>The server's certificate MUST contain an ECDSA-capable public
          key, it MUST be signed with ECDSA, and it MUST use SHA-256, SHA-384,
          or SHA-512. The Signature Algorithms extension (Section 7.4.1.4.1 of
          <xref target="RFC5246"/>) MUST be used to indicate support of those
          signature and hash algorithms. If a client certificate is used, the
          same conditions apply to it. The acceptable choices of hashes and
          curves that can be used with each ciphersuite are detailed in <xref
          target="reqts"/>.</t>
      </list>
      </t>
-->

    </section>
	  

  </back>
</rfc>
