| Network Working Group | M. Thomson |
| Internet-Draft | Mozilla |
| Intended status: Standards Track | May 18, 2016 |
| Expires: November 19, 2016 |
Cipher Suites for Negotiating Zero Round Trip (0-RTT) Transport Layer Security (TLS) with Renewed Certificate Authentication
draft-thomson-tls-0rtt-and-certs-00
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.
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 19, 2016.
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 proof that they control authentication keys without losing the latency advantages provided by the 0-RTT mode.
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].
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]. 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].
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.
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.
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
| [RFC0793] | Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981. |
TBD.