Internet DRAFT - draft-thomson-tls-offline-config
draft-thomson-tls-offline-config
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]
