One document matched: draft-thomson-tls-0rtt-and-certs-00.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-thomson-tls-0rtt-and-certs-00" category="std">

  <front>
    <title abbrev="TLS 0-RTT Certificates">Cipher Suites for Negotiating Zero Round Trip (0-RTT) Transport Layer Security (TLS) with Renewed Certificate Authentication</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2016"/>

    
    
    

    <abstract>


<t>New cipher suites are defined that allow a client to use zero round trip (0-RTT)
with Transport Layer Security (TLS), while also enabling the peers to renewed
certificate-based authentication.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Transport Layer Security version 1.3 (TLS 1.3) <xref target="I-D.ietf-tls-tls13"></xref> defines a
zero round trip (0-RTT) handshake mode for connections where client and server
have previously communicated.  In the two defined 0-RTT modes, keying material
from a previous connection is used as a pre-shared key.</t>

<t>A 0-RTT handshake can rely entirely on the pre-shared key.  These handshakes use
cipher suites denoted <spanx style="verb">TLS_PSK_WITH_*</spanx>.  Alternative modes use the pre-shared
key to authenticate the connection and secure any 0-RTT data, but then a fresh
ephemeral Diffie-Hellman (or elliptic curve Diffie-Hellman) key exchange is
performed.  These handshakes use cipher suites denoted <spanx style="verb">TLS_DHE_PSK_WITH_*</spanx> or
<spanx style="verb">TLS_ECDHE_PSK_WITH_*</spanx>.</t>

<t>Neither of the two 0-RTT handshake modes permits either client or server to send
the Certificate and CertificateVerify authentication messages.  Endpoints are
expected to store any authentication state with any resumption state.  This
means that endpoints are unable to update their understanding that a peer has
continuing access to authentication keys without choosing a one round trip
handshake mode and sacrificing any potential performance gained by 0-RTT.</t>

<t>This document defines a third mode for 0-RTT, where the pre-shared key is used
to authenticate and protect 0-RTT data only.  The remainder of the handshake is
identical to a regular one round trip handshake with the only difference being
that the resumption secret is mixed into the key schedule.  This allows peers to
provide fresh proof that they control authentication keys without losing the
latency advantages provided by the 0-RTT mode.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document.
It’s not shouting; when they are capitalized, they have the special meaning
defined in <xref target="RFC2119"></xref>.</t>

</section>
</section>
<section anchor="new-cipher-suites" title="New Cipher Suites">

<t>The following cipher suites are defined:</t>

<t><spanx style="verb">
TLS_ECDHE_PSK_ECDSA_WITH_AES_128_GCM_SHA256 = 0xXXXX
TLS_ECDHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX
TLS_DHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX
TLS_ECDHE_PSK_ECDSA_WITH_AES_256_GCM_SHA384 = 0xXXXX
TLS_ECDHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX
TLS_DHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX
TLS_ECDHE_PSK_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX
TLS_ECDHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX
TLS_DHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX
</spanx></t>

<t>All these cipher suites include the use of pre-shared keys and therefore permit
the use of 0-RTT.  These cipher suites can only be used with TLS 1.3.  All
include server authentication.  A server MAY request client authentication by
sending a CertificateRequest if it negotiates one of these cipher suites.</t>

<t>All the necessary cryptographic operations and the key schedule are as described
in <xref target="I-D.ietf-tls-tls13"></xref>.</t>

<t>These cipher suites use a pre-shared key for 0-RTT data, with subsequent data
protected by both the PSK and an ephemeral key exchange using finite field or
elliptic curve Diffie-Hellman.  The pre-shared key forms the static secret (SS)
and the ephemeral key exchange produces the ephemeral secret (ES).  DHE_PSK_RSA
suites use finite field Diffie-Hellman key exchange <xref target="DH"></xref>; ECDHE_PSK_ECDSA and
ECDHE_PSK_RSA suites use elliptic curve Diffie-Hellman key exchange <xref target="X962"></xref>.</t>

<t>These cipher suites are all authenticated using both the pre-shared key and a
signature, either from an RSA certificate <xref target="RFC3447"></xref> (for DHE_PSK_RSA and
ECDHE_PSK_RSA), or an ECDSA certificate (for ECDHE_PSK_ECDSA) <xref target="X962"></xref>.</t>

<t>AES_128_GCM and AES_256_GCM use the AEAD_AES_128_GCM and AEAD_AES_256_GCM
authenticated encryption defined in <xref target="RFC5116"></xref>.  These are similar to the other
AES-GCM modes that are described in [RFC5288].  CHACHA20_POLY1305 cipher suites
use the authenticated encryption defined in <xref target="RFC7539"></xref>.  Other ChaCha20-Poly1305
modes are described in [I-D.ietf-tls-chacha20-poly1305].  All authenticated
encryption modes use the nonce formulation from <xref target="I-D.ietf-tls-tls13"></xref>.</t>

<t>Suites ending with SHA256 use SHA-256 for the pseudorandom function; suites
ending with SHA384 use SHA-384 <xref target="FIPS180-4"></xref>.</t>

</section>
<section anchor="combining-certificate-and-psk-authentication" title="Combining Certificate and PSK Authentication">

<t>TLS 1.3 forbids a server from selecting different values for many of the
connection parameters when resuming a connection.  Though a client might need to
offer a choice in order to support a fallback to a 1-RTT handshake, a server
cannot change parameters such as the selected application layer protocol
[RFC7301].  Though it is theoretically possible to offer a different certificate
with these cipher suites, servers MUST NOT change certificates when resuming.
When resuming, clients MUST treat a change in certificate as a fatal error.</t>

<t>Outside of their use with 0-RTT, these cipher suites also permit the use of a
combination of pre-shared key and certificate authentication.  No real use case
for this has been unearthed other than with the use of resumption.</t>

<t>The cached-info extension <xref target="I-D.ietf-tls-cached-info"></xref> can be used to reduce the
size of a handshake, allowing more space for application data.  Since the server
certificate is not permitted to change when using 0-RTT with one of these cipher
suites, this extension trivially saves a considerable amount of space.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>Data sent after the Finished messages in the complete handshake are protected
based on both the ephemeral key exchange and the pre-shared key.  Learning
either an (EC)DHE private key or the pre-shared key is insufficient to
compromise the record protection.</t>

<t>The combination of pre-shared key and certificate authentication relies on peers
maintaining the confidentiality of the pre-shared key for the confidentiality
and integrity of 0-RTT data.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>IANA is requested to add the following entries in the TLS Cipher Suite Registry:</t>

<t><spanx style="verb">
TLS_ECDHE_PSK_ECDSA_WITH_AES_128_GCM_SHA256 = 0xXXXX
TLS_ECDHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX
TLS_DHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX
TLS_ECDHE_PSK_ECDSA_WITH_AES_256_GCM_SHA384 = 0xXXXX
TLS_ECDHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX
TLS_DHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX
TLS_ECDHE_PSK_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX
TLS_ECDHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX
TLS_DHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX
</spanx></t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<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>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC3447' target='http://www.rfc-editor.org/info/rfc3447'>
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'><organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></author>
<date year='2003' month='February' />
<abstract><t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3447'/>
<seriesInfo name='DOI' value='10.17487/RFC3447'/>
</reference>



<reference  anchor='RFC5116' target='http://www.rfc-editor.org/info/rfc5116'>
<front>
<title>An Interface and Algorithms for Authenticated Encryption</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<date year='2008' month='January' />
<abstract><t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5116'/>
<seriesInfo name='DOI' value='10.17487/RFC5116'/>
</reference>



<reference  anchor='RFC7539' target='http://www.rfc-editor.org/info/rfc7539'>
<front>
<title>ChaCha20 and Poly1305 for IETF Protocols</title>
<author initials='Y.' surname='Nir' fullname='Y. Nir'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</t><t>This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide.  It is a product of the Crypto Forum Research Group (CFRG).</t></abstract>
</front>
<seriesInfo name='RFC' value='7539'/>
<seriesInfo name='DOI' value='10.17487/RFC7539'/>
</reference>



<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='March' day='22' year='2016' />

<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol.  The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-12.txt' />
</reference>



<reference anchor='I-D.ietf-tls-cached-info'>
<front>
<title>Transport Layer Security (TLS) Cached Information Extension</title>

<author initials='S' surname='Santesson' fullname='Stefan Santesson'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<date month='May' day='11' year='2016' />

<abstract><t>Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs).  This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).  This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-cached-info-23' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-23.txt' />
</reference>


<reference anchor="DH" >
  <front>
    <title>New Directions in Cryptography</title>
    <author initials="W." surname="Diffie">
      <organization></organization>
    </author>
    <author initials="M." surname="Hellman">
      <organization></organization>
    </author>
    <date year="1977" month="June"/>
  </front>
  <seriesInfo name="IEEE Transactions on Information Theory, V.IT-22 n.6" value=""/>
</reference>
<reference anchor="X962" >
  <front>
    <title>Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
    <author >
      <organization>ANSI</organization>
    </author>
    <date year="1998"/>
  </front>
  <seriesInfo name="ANSI" value="X9.62"/>
</reference>
<reference anchor="FIPS180-4" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
  <front>
    <title>NIST FIPS 180-4, Secure Hash Standard</title>
    <author initials="National Institute of Standards and Technology, U.S." surname="Department of Commerce" fullname="NIST">
      <organization></organization>
    </author>
    <date year="2012" month="March"/>
  </front>
</reference>


    </references>

    <references title='Informative References'>





<reference  anchor='RFC0793' target='http://www.rfc-editor.org/info/rfc793'>
<front>
<title>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='J. Postel'><organization /></author>
<date year='1981' month='September' />
</front>
<seriesInfo name='STD' value='7'/>
<seriesInfo name='RFC' value='793'/>
<seriesInfo name='DOI' value='10.17487/RFC0793'/>
</reference>




    </references>


<section anchor="acknowledgments" title="Acknowledgments">

<t>TBD.</t>

</section>


  </back>
</rfc>