idnits 2.17.1 draft-thomson-tls-0rtt-and-certs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 24, 2016) is 2894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0793' is defined on line 275, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-12 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) -- Possible downref: Non-RFC (?) normative reference: ref. 'X962' -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Updates: I-D.ietf-tls-tls13 (if May 24, 2016 5 approved) 6 Intended status: Standards Track 7 Expires: November 25, 2016 9 Cipher Suites for Negotiating Zero Round Trip (0-RTT) Transport Layer 10 Security (TLS) with Renewed Certificate Authentication 11 draft-thomson-tls-0rtt-and-certs-01 13 Abstract 15 New cipher suites are defined that allow a client to use zero round 16 trip (0-RTT) with Transport Layer Security (TLS), while also enabling 17 the peers to renewed certificate-based authentication. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 25, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 55 2. New Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Combining Certificate and PSK Authentication . . . . . . . . 4 57 4. Signaling Support . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Transport Layer Security version 1.3 (TLS 1.3) [I-D.ietf-tls-tls13] 69 defines a zero round trip (0-RTT) handshake mode for connections 70 where client and server have previously communicated. In the two 71 defined 0-RTT modes, keying material from a previous connection is 72 used as a pre-shared key. 74 A 0-RTT handshake can rely entirely on the pre-shared key. These 75 handshakes use cipher suites denoted "TLS_PSK_WITH_*". Alternative 76 modes use the pre-shared key to authenticate the connection and 77 secure any 0-RTT data, but then a fresh ephemeral Diffie-Hellman (or 78 elliptic curve Diffie-Hellman) key exchange is performed. These 79 handshakes use cipher suites denoted "TLS_DHE_PSK_WITH_*" or 80 "TLS_ECDHE_PSK_WITH_*". 82 Neither of the two 0-RTT handshake modes permits either client or 83 server to send the Certificate and CertificateVerify authentication 84 messages. Endpoints are expected to store any authentication state 85 with any resumption state. This means that endpoints are unable to 86 update their understanding that a peer has continuing access to 87 authentication keys without choosing a one round trip handshake mode 88 and sacrificing any potential performance gained by 0-RTT. 90 This document defines a third mode for 0-RTT, where the pre-shared 91 key is used to authenticate and protect 0-RTT data only. The 92 remainder of the handshake is identical to a regular one round trip 93 handshake with the only difference being that the resumption secret 94 is mixed into the key schedule. This allows peers to provide fresh 95 proof that they control authentication keys without losing the 96 latency advantages provided by the 0-RTT mode. 98 1.1. Notational Conventions 100 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 101 document. It's not shouting; when they are capitalized, they have 102 the special meaning defined in [RFC2119]. 104 2. New Cipher Suites 106 The following cipher suites are defined: 108 "TLS_ECDHE_PSK_ECDSA_WITH_AES_128_GCM_SHA256 = 0xXXXX 109 TLS_ECDHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX 110 TLS_DHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX 111 TLS_ECDHE_PSK_ECDSA_WITH_AES_256_GCM_SHA384 = 0xXXXX 112 TLS_ECDHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX 113 TLS_DHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX 114 TLS_ECDHE_PSK_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX 115 TLS_ECDHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX 116 TLS_DHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX " 118 All these cipher suites include the use of pre-shared keys and 119 therefore permit the use of 0-RTT. These cipher suites can only be 120 used with TLS 1.3. All include server authentication. A server MAY 121 request client authentication by sending a CertificateRequest if it 122 negotiates one of these cipher suites. 124 All the necessary cryptographic operations and the key schedule are 125 as described in [I-D.ietf-tls-tls13]. 127 These cipher suites use a pre-shared key for 0-RTT data, with 128 subsequent data protected by both the PSK and an ephemeral key 129 exchange using finite field or elliptic curve Diffie-Hellman. The 130 pre-shared key forms the static secret (SS) and the ephemeral key 131 exchange produces the ephemeral secret (ES). DHE_PSK_RSA suites use 132 finite field Diffie-Hellman key exchange [DH]; ECDHE_PSK_ECDSA and 133 ECDHE_PSK_RSA suites use elliptic curve Diffie-Hellman key exchange 134 [X962]. 136 These cipher suites are all authenticated using both the pre-shared 137 key and a signature, either from an RSA certificate [RFC3447] (for 138 DHE_PSK_RSA and ECDHE_PSK_RSA), or an ECDSA certificate (for 139 ECDHE_PSK_ECDSA) [X962]. 141 AES_128_GCM and AES_256_GCM use the AEAD_AES_128_GCM and 142 AEAD_AES_256_GCM authenticated encryption defined in [RFC5116]. 144 These are similar to the other AES-GCM modes that are described in 145 [RFC5288]. CHACHA20_POLY1305 cipher suites use the authenticated 146 encryption defined in [RFC7539]. Other ChaCha20-Poly1305 modes are 147 described in [I-D.ietf-tls-chacha20-poly1305]. All authenticated 148 encryption modes use the nonce formulation from [I-D.ietf-tls-tls13]. 150 Suites ending with SHA256 use SHA-256 for the pseudorandom function; 151 suites ending with SHA384 use SHA-384 [FIPS180-4]. 153 3. Combining Certificate and PSK Authentication 155 TLS 1.3 forbids a server from selecting different values for many of 156 the connection parameters when resuming a connection. Though a 157 client might need to offer a choice in order to support a fallback to 158 a 1-RTT handshake, a server cannot change parameters such as the 159 selected application layer protocol [RFC7301]. Though it is 160 theoretically possible to offer a different certificate with these 161 cipher suites, servers MUST NOT change certificates when resuming. 162 When resuming, clients MUST treat a change in certificate as a fatal 163 error. 165 Outside of their use with 0-RTT, these cipher suites also permit the 166 use of a combination of pre-shared key and certificate 167 authentication. No real use case for this has been unearthed other 168 than with the use of resumption. 170 The cached-info extension [I-D.ietf-tls-cached-info] can be used to 171 reduce the size of a handshake, allowing more space for application 172 data. Since the server certificate is not permitted to change when 173 using 0-RTT with one of these cipher suites, this extension trivially 174 saves a considerable amount of space. 176 4. Signaling Support 178 A TLS server that supports these cipher suites needs to indicate that 179 it does so in the NewSessionTicket message. A new 180 "allow_dhe_cert_resumption" value is added to TicketFlags that, when 181 set, indicates that the server will accept resumption with cipher 182 suites that do both (EC)DHE and certificate authentication. 184 enum { 185 allow_early_data(1), 186 allow_dhe_resumption(2), 187 allow_psk_resumption(4), 188 allow_dhe_cert_resumption(8) // new 189 } TicketFlags; 191 There is no IANA registry for these values, so [I-D.ietf-tls-tls13] 192 is updated to include this value. 194 5. Security Considerations 196 Data sent after the Finished messages in the complete handshake are 197 protected based on both the ephemeral key exchange and the pre-shared 198 key. Learning either an (EC)DHE private key or the pre-shared key is 199 insufficient to compromise the record protection. 201 The combination of pre-shared key and certificate authentication 202 relies on peers maintaining the confidentiality of the pre-shared key 203 for the confidentiality and integrity of 0-RTT data. 205 6. IANA Considerations 207 IANA is requested to add the following entries in the TLS Cipher 208 Suite Registry: 210 "TLS_ECDHE_PSK_ECDSA_WITH_AES_128_GCM_SHA256 = 0xXXXX 211 TLS_ECDHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX 212 TLS_DHE_PSK_RSA_WITH_AES_128_GCM_SHA256 = 0xXXXX 213 TLS_ECDHE_PSK_ECDSA_WITH_AES_256_GCM_SHA384 = 0xXXXX 214 TLS_ECDHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX 215 TLS_DHE_PSK_RSA_WITH_AES_256_GCM_SHA384 = 0xXXXX 216 TLS_ECDHE_PSK_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX 217 TLS_ECDHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX 218 TLS_DHE_PSK_RSA_WITH_CHACHA20_POLY1305_SHA256 = 0xXXXX " 220 7. References 222 7.1. Normative References 224 [DH] Diffie, W. and M. Hellman, "New Directions in 225 Cryptography", IEEE Transactions on Information Theory, 226 V.IT-22 n.6 , June 1977. 228 [FIPS180-4] 229 Department of Commerce, National., "NIST FIPS 180-4, 230 Secure Hash Standard", March 2012, 231 . 234 [I-D.ietf-tls-cached-info] 235 Santesson, S. and H. Tschofenig, "Transport Layer Security 236 (TLS) Cached Information Extension", draft-ietf-tls- 237 cached-info-23 (work in progress), May 2016. 239 [I-D.ietf-tls-tls13] 240 Rescorla, E., "The Transport Layer Security (TLS) Protocol 241 Version 1.3", draft-ietf-tls-tls13-12 (work in progress), 242 March 2016. 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 250 Standards (PKCS) #1: RSA Cryptography Specifications 251 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 252 2003, . 254 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 255 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 256 . 258 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 259 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 260 . 262 [X962] ANSI, "Public Key Cryptography For The Financial Services 263 Industry: The Elliptic Curve Digital Signature Algorithm 264 (ECDSA)", ANSI X9.62, 1998. 266 7.2. Informative References 268 [I-D.ietf-tls-chacha20-poly1305] 269 Langley, A., Chang, W., Mavrogiannopoulos, N., 270 Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305 271 Cipher Suites for Transport Layer Security (TLS)", draft- 272 ietf-tls-chacha20-poly1305-04 (work in progress), December 273 2015. 275 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 276 RFC 793, DOI 10.17487/RFC0793, September 1981, 277 . 279 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 280 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 281 DOI 10.17487/RFC5288, August 2008, 282 . 284 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 285 "Transport Layer Security (TLS) Application-Layer Protocol 286 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 287 July 2014, . 289 Appendix A. Acknowledgments 291 TBD. 293 Author's Address 295 Martin Thomson 296 Mozilla 298 Email: martin.thomson@gmail.com