Internet DRAFT - draft-thomson-tls-0rtt-and-certs
draft-thomson-tls-0rtt-and-certs
Network Working Group M. Thomson
Internet-Draft Mozilla
Updates: I-D.ietf-tls-tls13 (if May 24, 2016
approved)
Intended status: Standards Track
Expires: November 25, 2016
Cipher Suites for Negotiating Zero Round Trip (0-RTT) Transport Layer
Security (TLS) with Renewed Certificate Authentication
draft-thomson-tls-0rtt-and-certs-01
Abstract
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.
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 November 25, 2016.
Copyright Notice
Copyright (c) 2016 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 November 25, 2016 [Page 1]
Internet-Draft TLS 0-RTT Certificates May 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. New Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 3
3. Combining Certificate and PSK Authentication . . . . . . . . 4
4. Signaling Support . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Transport Layer Security version 1.3 (TLS 1.3) [I-D.ietf-tls-tls13]
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.
A 0-RTT handshake can rely entirely on the pre-shared key. These
handshakes use cipher suites denoted "TLS_PSK_WITH_*". 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 "TLS_DHE_PSK_WITH_*" or
"TLS_ECDHE_PSK_WITH_*".
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.
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
Thomson Expires November 25, 2016 [Page 2]
Internet-Draft TLS 0-RTT Certificates May 2016
proof that they control authentication keys without losing the
latency advantages provided by the 0-RTT mode.
1.1. Notational Conventions
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 [RFC2119].
2. New Cipher Suites
The following cipher suites are defined:
"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 "
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.
All the necessary cryptographic operations and the key schedule are
as described in [I-D.ietf-tls-tls13].
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 [DH]; ECDHE_PSK_ECDSA and
ECDHE_PSK_RSA suites use elliptic curve Diffie-Hellman key exchange
[X962].
These cipher suites are all authenticated using both the pre-shared
key and a signature, either from an RSA certificate [RFC3447] (for
DHE_PSK_RSA and ECDHE_PSK_RSA), or an ECDSA certificate (for
ECDHE_PSK_ECDSA) [X962].
AES_128_GCM and AES_256_GCM use the AEAD_AES_128_GCM and
AEAD_AES_256_GCM authenticated encryption defined in [RFC5116].
Thomson Expires November 25, 2016 [Page 3]
Internet-Draft TLS 0-RTT Certificates May 2016
These are similar to the other AES-GCM modes that are described in
[RFC5288]. CHACHA20_POLY1305 cipher suites use the authenticated
encryption defined in [RFC7539]. Other ChaCha20-Poly1305 modes are
described in [I-D.ietf-tls-chacha20-poly1305]. All authenticated
encryption modes use the nonce formulation from [I-D.ietf-tls-tls13].
Suites ending with SHA256 use SHA-256 for the pseudorandom function;
suites ending with SHA384 use SHA-384 [FIPS180-4].
3. Combining Certificate and PSK Authentication
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.
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.
The cached-info extension [I-D.ietf-tls-cached-info] 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.
4. Signaling Support
A TLS server that supports these cipher suites needs to indicate that
it does so in the NewSessionTicket message. A new
"allow_dhe_cert_resumption" value is added to TicketFlags that, when
set, indicates that the server will accept resumption with cipher
suites that do both (EC)DHE and certificate authentication.
enum {
allow_early_data(1),
allow_dhe_resumption(2),
allow_psk_resumption(4),
allow_dhe_cert_resumption(8) // new
} TicketFlags;
Thomson Expires November 25, 2016 [Page 4]
Internet-Draft TLS 0-RTT Certificates May 2016
There is no IANA registry for these values, so [I-D.ietf-tls-tls13]
is updated to include this value.
5. Security Considerations
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.
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.
6. IANA Considerations
IANA is requested to add the following entries in the TLS Cipher
Suite Registry:
"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 "
7. References
7.1. Normative References
[DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977.
[FIPS180-4]
Department of Commerce, National., "NIST FIPS 180-4,
Secure Hash Standard", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls-
cached-info-23 (work in progress), May 2016.
Thomson Expires November 25, 2016 [Page 5]
Internet-Draft TLS 0-RTT Certificates May 2016
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-12 (work in progress),
March 2016.
[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>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<http://www.rfc-editor.org/info/rfc7539>.
[X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998.
7.2. Informative References
[I-D.ietf-tls-chacha20-poly1305]
Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
Cipher Suites for Transport Layer Security (TLS)", draft-
ietf-tls-chacha20-poly1305-04 (work in progress), December
2015.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
DOI 10.17487/RFC5288, August 2008,
<http://www.rfc-editor.org/info/rfc5288>.
Thomson Expires November 25, 2016 [Page 6]
Internet-Draft TLS 0-RTT Certificates May 2016
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.
Appendix A. Acknowledgments
TBD.
Author's Address
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
Thomson Expires November 25, 2016 [Page 7]