[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

tls                                                           M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                        October 19, 2015
Expires: April 21, 2016


    Offline Server Configuration for Zero Round Trip Transport Layer
                                Security
                  draft-thomson-tls-offline-config-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Thomson                  Expires April 21, 2016                 [Page 1]


Internet-Draft            TLS Offline Zero-RTT              October 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Offline Server Configuration Format . . . . . . . . . . . . .   3
     2.1.  Offline Configuration Authentication  . . . . . . . . . .   3
   3.  Server Configuration Extensions . . . . . . . . . . . . . . .   4
     3.1.  Server Cipher Suites  . . . . . . . . . . . . . . . . . .   4
     3.2.  Certificate . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Certificate Request . . . . . . . . . . . . . . . . . . .   5
     3.4.  Supported Groups  . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

   TLS 1.3 [I-D.ietf-tls-tls13] 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.

   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.

1.1.  Terminology

   RFC 2119 [RFC2119] defines the terms MUST, SHOULD, and MAY.





Thomson                  Expires April 21, 2016                 [Page 2]


Internet-Draft            TLS Offline Zero-RTT              October 2015


2.  Offline Server Configuration Format

   The offline server configuration is simply a ServerConfiguration,
   that is optionally signed.

      struct {
          ServerConfiguration config;
          digitally-signed struct {
              ServerConfiguration config;
          };
      } OfflineServerConfiguration;

              Figure 1: OfflineServerConfiguration Definition

   Extensions to the ServerConfiguration object are used to convey the
   additional information needed for use outside of the TLS handshake
   are defined in Section 3.  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.

2.1.  Offline Configuration Authentication

   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.

   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).

   The process for constructing and verifying digital signatures is
   defined in [I-D.ietf-tls-tls13].  The context string for the
   signature on an offline server configuration is "TLS 1.3, offline
   ServerConfiguration".

   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
   [RFC7250].  A client that does not support the algorithms that the
   server selects will simply be unable to use the configuration.

   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
   [RFC2818] or [RFC6125]).





Thomson                  Expires April 21, 2016                 [Page 3]


Internet-Draft            TLS Offline Zero-RTT              October 2015


3.  Server Configuration Extensions

   The offline server configuration uses the same ServerConfiguration
   format that is defined in [I-D.ietf-tls-tls13], with extensions to
   carry the additional information that a client would ordinarily
   obtain from the TLS handshake.

      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;

             Figure 2: ServerConfiguration Extension Additions

   Section 3 shows a modified version of the ConfigurationExtension
   structure from [I-D.ietf-tls-tls13] that includes the extensions
   added in this document.  These extensions are defined in detail in
   subsequent sections.

3.1.  Server Cipher Suites

   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.

   The "server_cipher_suites" 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



Thomson                  Expires April 21, 2016                 [Page 4]


Internet-Draft            TLS Offline Zero-RTT              October 2015


   symmetric algorithm than the server ultimately selects.  The key
   exchange and signature algorithms MUST be the same.

      CipherSuite ServerCipherSuites<2..2^16-2>;

               Figure 3: ServerCipherSuites Extension Format

   An offline server configuration MUST NOT be used if it does not
   include the "server_cipher_suites" extension.

   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.

   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.

   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.

3.2.  Certificate

   The content of the "certificate" 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.

3.3.  Certificate Request

   The content of the "certificate_request" 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.

   Including the "certificate_request" extension is only necessary when
   the server configuration permits client authentication.  That is,
   when the "early_data_type" is set to either "client_authentication"
   or "client_authentication_and_data".





Thomson                  Expires April 21, 2016                 [Page 5]


Internet-Draft            TLS Offline Zero-RTT              October 2015


3.4.  Supported Groups

   The content of the "supported_groups" server configuration extension
   is identical to that of the "supported_groups" hello extension in
   both syntax and semantics.  The extension carries a NamedGroupList
   object as defined in [I-D.ietf-tls-tls13].  This is used by a client
   to select a client certificate for which a signature can be
   successfully consumed by the server.

4.  Security Considerations

   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
   [I-D.ietf-tls-tls13].

   Server configurations that are generated offline MUST include a
   signature.  Failure to properly authenticate a server configuration
   (see Section 2.1) 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.

5.  IANA Considerations

   This document registers the following ServerConfiguration extensions
   in the registry established by [I-D.ietf-tls-tls13]:

   o  server_cipher_suites (Section 3.1)

   o  certificate (Section 3.2)

   o  certificate_request (Section 3.3)

   o  supported_groups (Section 3.4)

6.  References

6.1.  Normative References

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-09 (work in progress),
              October 2015.




Thomson                  Expires April 21, 2016                 [Page 6]


Internet-Draft            TLS Offline Zero-RTT              October 2015


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

6.2.  Informative References

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
              RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "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)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <http://www.rfc-editor.org/info/rfc6125>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

Appendix A.  Acknowledgements

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

Author's Address

   Martin Thomson
   Mozilla

   Email: martin.thomson@gmail.com















Thomson                  Expires April 21, 2016                 [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/