One document matched: draft-thomson-tls-offline-config-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.20 -->

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

<rfc ipr="trust200902" docName="draft-thomson-tls-offline-config-00" category="std">

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

  <front>
    <title abbrev="TLS Offline Zero-RTT">Offline Server Configuration for Zero Round Trip Transport Layer Security</title>

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

    <date year="2015"/>

    <area>SEC</area>
    <workgroup>tls</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Zero round trip operation in TLS relies on a client knowing about a server
configuration prior to establishing a connection.  TLS provides a mechanism for
a server to provide a configuration during a handshake so that subsequent
connections can send encrypted data in its first flight of messages.  This
document defines a format for this configuration information that can be used
outside of TLS.</t>



    </abstract>


  </front>

  <middle>


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

<t>A client that establishes a TLS connection to a server is unable to send any
encrypted data to the server prior to receiving a server configuration.  This
introduces a minimum of one round trip of latency to TLS connections.</t>

<t>TLS 1.3 <xref target="I-D.ietf-tls-tls13"></xref> describes a zero round trip mode of operation that
allows a client to send replayable data to a server.  A server configuration is
provided to clients in an initial handshake.  That configuration is used by the
client to encrypt the first flight of messages it sends in subsequent
connections.  While this first flight of messages can be replayed by an
attacker, it has both confidentiality and integrity protection.  This enables
use cases where the need to reduce latency is important, but replay protection
is either not needed, or provided by other means.</t>

<t>This document describes how a server configuration can be established outside of
the TLS handshake.  This allows for alternative methods of delivery for the
server configuration.</t>

<section anchor="terms" title="Terminology">

<t>RFC 2119 <xref target="RFC2119"></xref> defines the terms MUST, SHOULD, and MAY.</t>

</section>
</section>
<section anchor="format" title="Offline Server Configuration Format">

<t>The offline server configuration is simply a ServerConfiguration, that is
optionally signed.</t>

<figure title="OfflineServerConfiguration Definition" anchor="container"><artwork><![CDATA[
   struct {
       ServerConfiguration config;
       digitally-signed struct {
           ServerConfiguration config;
       };
   } OfflineServerConfiguration;
]]></artwork></figure>

<t>Extensions to the ServerConfiguration object are used to convey the additional
information needed for use outside of the TLS handshake are defined in
<xref target="extensions"/>.  An offline configuration MUST include the certificate and
server_cipher_suites extensions.  An offline configuration that requests or
permits client authentication MUST include the certificate_request extension.</t>

<section anchor="authentication" title="Offline Configuration Authentication">

<t>A client MUST NOT use an offline server configuration unless it has been
successfully authenticated.  This includes signature validation, plus additional
checks on the included certificate.</t>

<t>The signature MUST be validated against the public key in the included
end-entity certificate (that is, the first certificate in the list of provided
certificates, if more than one is included).</t>

<t>The process for constructing and verifying digital signatures is defined in
<xref target="I-D.ietf-tls-tls13"></xref>.  The context string for the signature on an offline server
configuration is “TLS 1.3, offline ServerConfiguration”.</t>

<t>The signature and hash algorithm that are used for signing can be any value that
the server supports, provided that it is compatible with the key in the server’s
end-entity certificate or public key <xref target="RFC7250"></xref>.  A client that does not support
the algorithms that the server selects will simply be unable to use the
configuration.</t>

<t>A client MUST NOT use an offline server configuration unless the end-entity
certificate or public key is successfully validated according to the rules for
the using protocol and application (such as <xref target="RFC2818"></xref> or <xref target="RFC6125"></xref>).</t>

</section>
</section>
<section anchor="extensions" title="Server Configuration Extensions">

<t>The offline server configuration uses the same ServerConfiguration format that
is defined in <xref target="I-D.ietf-tls-tls13"></xref>, with extensions to carry the additional
information that a client would ordinarily obtain from the TLS handshake.</t>

<figure title="ServerConfiguration Extension Additions" anchor="configext"><artwork><![CDATA[
   enum {
       server_cipher_suites(0), certificate(1),
       certificate_request(2), supported_groups(3),
       (65535)
   } ConfigurationExtensionType;

   struct {
       ConfigurationExtensionType extension_type;
       uint16 length;
       select (extension_type) {
           case server_cipher_suites:
               ServerCipherSuites;
           case certificate:
               Certificate;
           case certificate_request:
               CertificateRequest;
           case supported_groups:
               NamedGroupList;
       } extension_data;
   } ConfigurationExtension;
]]></artwork></figure>

<t><xref target="extensions"/> shows a modified version of the ConfigurationExtension structure
from <xref target="I-D.ietf-tls-tls13"></xref> that includes the extensions added in this document.
These extensions are defined in detail in subsequent sections.</t>

<section anchor="server_cipher_suites" title="Server Cipher Suites">

<t>A server configuration that appears in a TLS handshake is implicitly bound to
the cipher suite that was negotiated in that handshake.  Outside of a TLS
handshake, a client need to be able to know which cipher suites are supported by
the server.</t>

<t>The <spanx style="verb">server_cipher_suites</spanx> extension to ServerConfiguration identifies the set
of cipher suites that the server is willing to use.  This only applies to the
replayable data that the client sends in its first flight; the remainder of the
handshake is protected using a cipher suite that is negotiated in the usual
fashion.  This implies that the replayable data may be protected with a
different symmetric algorithm than the server ultimately selects.  The key
exchange and signature algorithms MUST be the same.</t>

<figure title="ServerCipherSuites Extension Format" anchor="ciphersuites"><artwork><![CDATA[
   CipherSuite ServerCipherSuites<2..2^16-2>;
]]></artwork></figure>

<t>An offline server configuration MUST NOT be used if it does not include the
<spanx style="verb">server_cipher_suites</spanx> extension.</t>

<t>A client can choose any cipher suite from this set for protecting its first
flight.  The client MUST include the selected value in the cipher_suites field
of its ClientHello.  A server MAY reject either the replayable data or the
entire handshake if the client selects a cipher suite that it does not claim to
support.</t>

<t>A server MAY choose to offer a smaller set of cipher suites for use in the
client’s first flight than it might support for a complete TLS handshake.</t>

<t>Clients MUST NOT alter the set of cipher suites they offer based on the value
seen in a ServerConfiguration.  While a falsified ServerConfiguration might
permit an attacker to decrypt replayable data, altering the set of cipher suites
would also permit a cipher suite downgrade attack.</t>

</section>
<section anchor="certificate" title="Certificate">

<t>The content of the <spanx style="verb">certificate</spanx> server configuration extension is identical to
that of the Certificate handshake message in both syntax and semantics.  Note
however that the ServerConfiguration extension limits the size of the
certificate chain to 65535 octets.</t>

</section>
<section anchor="certificate_request" title="Certificate Request">

<t>The content of the <spanx style="verb">certificate_request</spanx> server configuration extension is
identical to that of the CertificateRequest message that a server sends to
request that a client authenticate in both syntax and semantics.  This is
included to allow the client to generate Certificate and CertificateVerify
messages that the server is able to use.</t>

<t>Including the <spanx style="verb">certificate_request</spanx> extension is only necessary when the server
configuration permits client authentication.  That is, when the
<spanx style="verb">early_data_type</spanx> is set to either <spanx style="verb">client_authentication</spanx> or
<spanx style="verb">client_authentication_and_data</spanx>.</t>

</section>
<section anchor="supported_groups" title="Supported Groups">

<t>The content of the <spanx style="verb">supported_groups</spanx> server configuration extension is
identical to that of the <spanx style="verb">supported_groups</spanx> hello extension in both syntax and
semantics.  The extension carries a NamedGroupList object as defined in
<xref target="I-D.ietf-tls-tls13"></xref>.  This is used by a client to select a client certificate
for which a signature can be successfully consumed by the server.</t>

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

<t>Enabling zero round trip TLS in this fashion does not alter the limitations of
sending data in the client’s first flight of messages.  In particular, the first
flight of data from the client is not protected from replay.  Details of these
limitations are provided in <xref target="I-D.ietf-tls-tls13"></xref>.</t>

<t>Server configurations that are generated offline MUST include a signature.
Failure to properly authenticate a server configuration (see <xref target="authentication"/>)
can allow an attacker to substitute keying material, allowing data that was
intended for a specific server to be encrypted toward a server of an attacker’s
choosing.  Though the first flight from the client is not protected from replay,
this would violate the integrity and confidentiality guarantees that are
provided.</t>

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

<t>This document registers the following ServerConfiguration extensions in the
registry established by <xref target="I-D.ietf-tls-tls13"></xref>:</t>

<t><list style="symbols">
  <t>server_cipher_suites (<xref target="server_cipher_suites"/>)</t>
  <t>certificate (<xref target="certificate"/>)</t>
  <t>certificate_request (<xref target="certificate_request"/>)</t>
  <t>supported_groups (<xref target="supported_groups"/>)</t>
</list></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='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='October' day='5' year='2015' />

<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-09' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-09.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>



<reference  anchor='RFC6125' target='http://www.rfc-editor.org/info/rfc6125'>
<front>
<title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organization /></author>
<author initials='J.' surname='Hodges' fullname='J. Hodges'><organization /></author>
<date year='2011' month='March' />
<abstract><t>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6125'/>
<seriesInfo name='DOI' value='10.17487/RFC6125'/>
</reference>



<reference  anchor='RFC7250' target='http://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>




    </references>


<section anchor="ack" title="Acknowledgements">

<t>This document is better for the contributions of Karthikeyan Bhargavan, Wan-Teh
Chang, Christian Huitema, Adam Langley, Eric Rescorla, and others.</t>

</section>


  </back>
</rfc>